Planning for security

Before installing, decide which user registry configuration you want to use for TADDM security. During the installation process, you must specify which user registry is used to authenticate TADDM users.

TADDM uses many forms of security, including user authentication and user authorization. User authentication ensures that a TADDM user is who the user claims to be. User authorization ensures that a TADDM user can manipulate TADDM objects and perform TADDM operations that the user is permitted to access.

The following table identifies the ways TADDM ensures that data that is collected during the discovery process is secure:

Table 1. Security features and benefits for the discovery process
Feature	Benefit
Credentials required for user of API access	Eliminates unauthorized access to information or control
Logging of user activity	Enables security audits
Utilize SSH for host access	Authenticates and secures discovery activity

Authentication

TADDM supports three types of user repositories that can be used to authenticate TADDM users: a TADDM file-based repository, LDAP repositories, and the federated repositories functions of IBM® WebSphere® Application Server. You can select the type of user registry that you want to use during the installation process. These types of registries are mutually exclusive.

TADDM file-based repository

The TADDM file-based repository is used for small proof-of-concept installations or environments where TADDM product integration that uses a single sign-on (SSO) is not required. The TADDM file-based repository requires that all users and groups (including passwords) are created, managed, and maintained within TADDM. To configure TADDM to use the file-based repository, select this repository during the TADDM installation.

LDAP registry

If your environment has a central LDAP registry, you can use this repository to authenticate TADDM users. TADDM supports LDAP authentication by using the following products:

IBM Tivoli® Directory Server V6.0, V6.2 or later
Microsoft Active Directory 2008 R2
OpenLDAP V2.4.26 and V2.3.43
Apache Directory Server V1.5.3

Note: However, If single sign-on is required, you must configure TADDM to use WebSphere federated repositories as the user registry.

WebSphere federated repositories

The WebSphere federated repositories feature is a flexible meta-repository within WebSphere that supports multiple types of repositories, including Microsoft Active Directory. If you use other Tivoli products in your environment, including IBM Tivoli Change and Configuration Management Database (IBM SmartCloud Control Desk (SCCD)) or Tivoli Business Service Manager (TBSM) you can configure TADDM to use WebSphere federated repositories.

To see supported versions of the products, go to the Supported versions section.

This configuration enables single sign-on (SSO) between Tivoli applications by using WebSphere Lightweight Third-Party Authentication (LTPA) tokens. For example, configuring TADDM for the same WebSphere federated repositories used by IBM Tivoli CCMDB or IBM SmartCloud Control Desk supports SSO for launch in context between IBM Tivoli CCMDB or IBM SmartCloud Control Desk and TADDM.

Planning for the future

If you cannot use the federated repositories functionality of IBM WebSphere Application Server, but you plan to install IBM Tivoli CCMDB or IBM SmartCloud Control Desk in the future, it is easier for you to move to federated repositories if you choose the LDAP user registry instead of the file-based user registry. If you use an LDAP user registry, you do not have to re-create your users when moving to federated repositories.

Authorization

TADDM supports two types of authorization: run time and data-level. These types of authorization are based on TADDM roles which are groups of permissions. The Data Management Portal manages the assignment of roles to users. This feature is not available through the Discovery Management Console. The following table shows the three core TADDM roles (administrator, operator, and supervisor) and their permissions.

Table 2. TADDM roles and permissions
Roles	Permissions
Administrator	Read, Update, Admin, Discover
Operator	Read
Supervisor	Read, Update, Discover

Runtime authorization

When using TADDM runtime authorization, the user interface (UI) and application programming interface (API) check specific TADDM permissions to prevent or authorize access to TADDM capabilities. The following list shows examples of runtime authorization:

The Admin permission is checked before a user administering users, groups, and roles through the Data Management Portal.
The Discover permission is checked before a user initiating TADDM discoveries or manually creating TADDM components in the Discovery Management Console.

Runtime authorization is always in effect and cannot be disabled.

Data-level authorization

When using TADDM data-level security, named groups of TADDM objects (access collections) are created to define groups of objects that are managed by particular users. Users are assigned a role and access collections of objects with which to interact. One virtual access collection, DefaultAccessCollection, represents access to all objects. The TADDM-specific permissions (Read, Update) are used with access collections so that a user can view and modify objects (contained by the access collections) that the user can access. You can set up access collections, roles, and users in the Discovery Management Console after you complete the installation process.

Data-level authorization is disabled by default and can be enabled by setting com.collation.security.enabledatalevelsecurity to true in the $COLLATION_HOME/etc/collation.properties file.

Multitenancy

TADDM can host multiple organizations or customers, allowing users to access the data that belongs to their organizations. Large companies and service providers might prefer multitenancy capabilities. TADDM supports multitenancy through the creation of access collections along organizational or customer lines.

For example, organization A's objects are grouped into access collections (A, B, and C). Organization B's objects are also grouped into access collections (D, E, and F). User #1 has administrator access (Read, Update, Admin, and Discover) for access collections (A, B, and C). User #2 has administrator access (Read, Update, Admin, and Discover) for access collections (D, E, and F). Therefore, each user can view the details of and modify the objects to which the user can access.

The TADDM user interface supports data-level security. If data-level security is enabled, a user can view details only about objects that are in access collections to which the user has access.

When planning for TADDM security, there are limitations:

Because all TADDM administrators have Admin permission, each administrator is able to administer all TADDM users, including users that are associated with a particular organization. TADDM does not have a hierarchy of administrators.
Data-level security does not apply to scopes. Therefore, any user with the Discovery permission can see all scope sets and scope groups, including those associated with other organizations or customers.
Some TADDM reports might show objects to which users do not have access. TADDM reports generated by using the Business Intelligence and Reporting Tools (BIRT) system, access the TADDM database directly and do not support data-level security.

Secure DB access

TADDM can use the SSL connection to the underlying database. Now only DB2 is supported in the SSL mode. You must configure all DB related SSL settings manually after installation for every installed server which has access to the database. Those servers are the domain server, primary storage server, secondary storage server, and enterprise server.