Security Overview

Note: If you are a system manager who is looking to control sensitive information in an enterprise environment, please review this topic:

You can establish security for the application, for the database, view, or any combination.

Also see: Securing Web Central for Production Deployment

View-Level Security

With view-level security, you can prohibit users from accessing views from a URL to which their role does not permit access.

Application Security

The business process owner or the application system administrator sets up security for the application using these features:

Archibus application security

Security groups determine the columns of data each user can review and edit. You implement security groups using the System domain's Security application. See Introducing Archibus Application Security for information.

Additionally, you can control the commands to which each user has access by implementing command access levels.

Archibus Hierarchical Security

Hierarchical security is a refinement to the regular security group codes and further controls access to columns of data (fields). It adds a flexible system for organizing security access into hierarchies so that the application security organization can reflect the structure of your organization. It also gives you the ability to aggregate security groups into roles so that all of the permissions that each type of staff member needs to execute their mission can be assigned in one step. For more information, see Hierarchical Security (Overview)

Virtual Private Archibus

Virtual Private Archibus is an extension of application security that controls access to rows of data (records). With this feature, you can partition your entire database by region, division, or organization, yet keep all of your data in one central database with a common set of rollup or validating codes. For information, see Application-Level Virtual Private Archibus and VPA Groups .

Note: Users of Oracle8i and later can alternately opt to take advantage of Archibus’s support for the Oracle Virtual Private Database Security features, which provide server-enforced, very specific access to data. For information, see Oracle Virtual Private Archibus.

Database Security

The database administrator (DBA) establishes security on the database using the database server program's security features.

Database Connection Roles and SQL Security

By default, Archibus projects establish three pools of connections to the database for data, schema information for the data dictionary, and security information user account information. If you examine the project list in \WEB-INF\config\afm-projects.xml , you will see that each database connection has one of these roles: data, schema, or security.

Each role specifies a database account and password to use to log into the database and retrieve data. All of the connections within each connection pool use the same user and password credentials.

By default, the program logs into the database as users AFM (for data and schema information) and as user AFM_SECURE for security information.

You can change the passwords for these database users, or the database user names themselves, in the afm-projects.xml file. Please see: Configuring Project Database Connections .

If you do not wish to store your database passwords in plaintext, you can encrypt them using the System / Archibus Administrator / Encrypt Passwords in Configuration Files task.

Adding Database Connection Roles

Some sites wish to enforce additional security and logging at the database level, and so they want to have different database user login information for different pools of users.

To do so, for the Archibus Roles (afm_roles) information, provide an SQL Login Password and SQL Login Username. All users of that roll will be logged into the database using the password and username for that role. The Archibus program will establish a connection pool for each unique database user (i.e. the connections are pooled by the common database credentials not by the role).

Platform Security

WebCentral uses parameterized queries to prevent SQL Injection.

WebCentral JavaScript encodes output (HTML entities) to prevent HTML Injection.

WebCentral validates file path to prevent path manipulation (directory traversal).

WebCentral sanitizes CR/LF sequences.