Users represent individuals that are known to CentraSite. You assign roles and permissions to users to specify which operations they can perform and which registry objects they can access. (Roles and permissions are discussed in more detail later in this guide.) Groups enable you to collectively assign roles and permissions to groups of users.
To interact with a CentraSite registry, an individual must have a user account with the registry.
A user account is represented by an instance of a User object. A User object contains basic attributes such as the name, email address and phone number for an individual. It also includes a link to the individual's user account in an external authentication system. This attribute is required if the User object represents an individual who will actually log on to CentraSite. You can customize the User object type to include additional attributes as necessary.
A user account can be activated or deactivated by an administrator. Active users are allowed to log on to CentraSite. Inactive users exist in the registry, but they are not permitted to log on to CentraSite. Additionally, permissions cannot be granted to inactive users, inactive users cannot be assigned ownership of an asset (although they will retain ownership of the assets that they already own), nor can they be assigned to groups. Administrators generally deactivate users who leave the company or otherwise cease to be valid users of the registry. If you want to delete a user from CentraSite, you must deactivate the user first.
Tip:
To keep your audit trail intact when a user leaves the registry,
simply deactivate that user and leave his or her existing assets in place. If
you delete the user or transfer the user's assets to someone else, the audit
trail for those assets will be lost.
You can also use inactive users to represent individuals who are actors within your SOA environment, but are not actual users of the registry. For example, you might model certain line-of-business managers as "users" in the CentraSite registry so that you can express associations between these individuals and various assets in the registry. Such users might never log on to CentraSite themselves, and therefore would not need to have an account that is active and linked to the external authentication system. However, the registry would know of these users, so assets could be associated with them. (Points-of-contact for external parties such as suppliers and distributors are additional individuals that you might want to model as inactive users.)
Note:
Because inactive users cannot be assigned to groups, users who are
inactive are not eligible to receive automatic email notifications from
CentraSite. You might want to take this point into consideration when
deciding whether to make a user inactive or active.
Only users who belong to a role that includes the "Manage Users" permission can add, modify and/or delete users on CentraSite. However, any user (including guests) can view other users of the registry.
Although CentraSite maintains its own database of user accounts, it authenticates users externally, either through the local operating system or an external directory service such as Active Directory or a Lightweight Directory Access Protocol (LDAP) server. Because authentication is handled by an external facility, it is not necessary for CentraSite to maintain its own set of user passwords. Password management is handled by your organization's existing authentication system.
By default, CentraSite is configured to authenticate users against the local operating system. While this configuration is adequate for initial experimentation and demonstration, it is generally not suitable for an enterprise-wide implementation of CentraSite. When you deploy CentraSite for actual use within your enterprise, you will need to configure it to authenticate users against a production-quality authentication service such as Active Directory or an LDAP server. Moreover, you should complete this configuration step before you begin creating organizations and setting up users, groups and roles.
When you configure CentraSite to use Active Directory or LDAP for user authentication, you map the user metadata from the authentication system to the User object in CentraSite. This enables CentraSite to import the metadata (e.g., name, phone number, email address) for a user from the external directory when you create an account for that user in CentraSite. (Be aware that this is a one-time import. CentraSite simply loads the appropriate metadata from the authentication system into its database. It does not attempt to keep the user metadata synchronized with the authentication system afterwards.)
When you create user accounts in CentraSite, you can define the accounts individually or you can use the "bulk load" facility to import multiple users from the authentication system at one time.
When you install an instance of CentraSite, it initially has two user accounts: an account for the bootstrap user and an account for the default user.
The bootstrap user refers to the user who installs CentraSite. This user is given a user account in the Default Organization and becomes the initial Organization Administrator and Primary Contact for that organization. This user is also given the CentraSite Administrator role, which gives him or her "super admin" privileges. You can choose to assign each of these roles to other users later in the deployment process.
The default user represents an internal user that owns the predefined objects installed with CentraSite. The default user exists for CentraSite's internal use. You cannot edit or delete this account. You cannot use the default user account to log on to CentraSite.
Note:
There are actually a few additional user accounts that CentraSite
creates for its own internal use, but the account for the default user is the
only "visible" account that you or your users are likely to
encounter while using CentraSite.
Generally, the bootstrap user creates the initial set of organizations. However, other users can perform this task if the bootstrap user adds those users to CentraSite and gives them the CentraSite Administrator role.
When you create an organization, CentraSite requires you to identify the users that will serve as the organization's administrator and as the organization's primary contact.
Organization Administrator. The organization administrator is a user that has the Organization Administrator role for the organization. An organization must have at least one user in the Organization Administrator role. It can have multiple users in this role. A user in one organization can serve as an organization administrator for another organization; however, this role is usually given to someone within the organization. An organization administrator performs administrative tasks for the organization, such as:
Adding users to the organization
Defining groups and roles
Defining custom lifecycle models for the organization
Creating child organizations
An Organization Administrator can also view, edit and delete any asset, policy or lifecycle model that belongs to his or her organization or to any of the organization's descendants.
Primary Contact. The primary contact is simply a user who acts as the point-of-contact for an organization. An organization has just one primary contact. The user who is designated as the primary contact does not receive any additional roles or permissions by serving in this capacity. You can optionally select the same user to serve as both the administrator and the primary contact for an organization, but CentraSite does not require you to do this. You can have different users serving in each of these capacities.
After an organization is created, and its organization administrator and primary contact are assigned, the organization administrator (or any user with "Manage Users" permission for the organization) can begin adding additional users to the organization.
CentraSite supports the concept of a guest user. Guests are users who can access the registry without a user account (i.e., they access the registry anonymously).
The capabilities given to a guest are determined by the set of permissions specified in the Guest role. Typically, you give guest users read-only access to a limited set of objects.
By default, guests are given permission to use the "asset catalog" pages in the CentraSite Control user interface. They can use these pages to browse the assets whose permissions extend to the system-defined group called "Everyone".
When you deploy CentraSite, think about the level of access you want to extend to guest users and configure the Guest role accordingly. Additionally, make sure that users who publish assets to your registry know that the Everyone group includes guest users, and that by granting access to this group, they enable access by anonymous users.
As a best practice, you should never give anything other than view permission to the Everyone group. This group should not be given permission to modify or delete registry objects.
When adding users to CentraSite, keep the following points in mind:
To access a CentraSite registry in any capacity other than as a guest, a user must have a user account on CentraSite, and that account must be associated with a user account in an external authentication system.
Users belong to organizations. You must create your organizations first and then add users to them.
A user can belong to one and only one organization.
As a general rule, users work with assets and objects that belong to their organization. However, an administrator can give users permissions to perform work in other organizations when necessary.
A group represents a specified set of users. A group can be empty or contain any number of users. It can contain users from different organizations.
Only administrators with "Manage Users" permission can create, edit and delete groups, however, all users (including guests) can view the groups that exist within an instance of CentraSite.
Within CentraSite, groups are used for the following purposes:
To assign roles to groups of users.
To give a group of users access to a specific object in the registry.
To identify the group of individuals who are authorized to approve certain types of requests.
To identify the target audience for certain policy actions (for example, the intended recipients of an email action).
CentraSite provides the following system-defined groups.
Users—The set of users that belong to an organization. Every organization has a Users group.
Members—The set of users that belong to an organization or any of its descendant organizations. Every organization has a Members group.
Everyone—The set of all users that are defined within an instance of CentraSite. This group includes guest users.
CentraSite manages the membership of these groups automatically. You cannot delete the system-defined groups or edit their membership. You can, however, edit the roles that are assigned to a system-defined group and use them in all of the same ways as you can a regular user-defined group.
CentraSite can use groups that are defined in the external authentication system. When you use an external group with CentraSite, the membership of the group is defined and managed by the authentication system, not by CentraSite (i.e., you cannot use CentraSite to add members to the group or delete members from the group).
When CentraSite executes a request that references an external group, it accesses the external authentication system to resolve the group's membership. It performs the requested activity for each user who is a member of the specified group and is also a registered user on CentraSite. Users that are named in the external group but are not registered CentraSite users are ignored.
You can use externally defined groups in exactly the same way as native groups that you define in CentraSite. For example, you can assign roles to externally defined groups and you can grant permissions to them.
If your authentication system already defines groups of users that are significant to your SOA environment (e.g., SOA Architects, SOA Project Review Team, SOA Managers), consider adding them to CentraSite as external groups. Doing this will simplify maintenance by eliminating the need to update two systems when the membership of a group changes.
Note:
Groups that are nested in the external authentication are supported
by CentraSite. (If you are using LDAP, note that only the "recurse
up" option is supported for group resolution. The "recurse
down" option is not supported.)
