When setting up security, you will need to follow a specific series of steps to configure the security system. The steps are as follows:
Roles. If not using the default Roles, create new roles. See Define Roles.
Permissions. Determine which Roles have what permissions by Resource and Resource Type, if you are not using the Default Permissions. See Set and Manage Permissions.
Authorization Realms. If not using the default Authorization Realms, one must be created. See Configure Authorization Realms.
Authentication Realms. If not using the default Authentication Realms, one must be created. See Configure Authentication Realms.
Users. Add users (which are associated with Roles) to the appropriate Authentication Realm. See Add Users. If using LDAP, see also Configure Authorization Realms.
In addition, if you use LDAP or other similar tools, you can import users into AnthillPro, and then map them to the security system. To do this, you'll need the appropriate permissions to that tool that allow AnthillPro to access it.
AnthillPro uses a flexible, role-based security model. Roles created and edited in this section as the building block to create security schemes. The default Roles that ship with AnthillPro can be edited to meet specific needs. If additional Roles are necessary, new ones may be created. You will need access to the System page in order to manage security.
Go to System > Roles under the Security menu.
On the Roles tab, click the Create Role button.
Configure Role:
Name the Role.
Require Secondary Authentication. Check the box to require Secondary Authentication.
Once a primary Authentication Realm is configured, the Secondary Authentication Realm adds a second layer of security. If this item is checked, every Authentication Realm that this Role belongs to will require that Secondary Authentication be configured. See Configure Authentication Realms.
Click Save then Done.
Permissions associate the role, resource, and an action that may be performed on the resource. Typical actions include the ability to read or view the resource (i.e., a project, workflow, agent, etc.); the ability to write to or modify the resource (e.g., add an agent property); the ability to modify the security settings for a resource; or the ability to execute (in the case of workflows) the resource. Generally, permissions fall within one of these groups:
Read or View, depending on the resource. Users assigned this permission can read (view), a resource, but will not be able to create or change a configuration. For example, a user with "read" permissions to an agent will be able to see that agent within the user interface, but will not have access to configure that agent.
Write permission includes the "read" permission, with the additional ability to perform a task using a specific resource. For example, a user with "write" permissions to an originating workflow can modify the workflow.
Execute (workflow only). Allows a user to run a particular workflow. Anyone with access to execute a build workflow must have at least read permissions. If the user must run a secondary workflow in a different environment, that user must also be assigned "use" permissions to the target environment(s).
Task Execute (workflow only). Allows the user to perform the same actions as the execute permission, but only through the Task interface. Note that the "task execute" permission does not allow users to manually run a secondary process, etc., and gives them no system permissions. This is useful in situations where AnthillPro users are only tasked with deploying, but not building, a project or workflow.
Security permission allows users to change the security settings for a specific resource. For example, a user with "security" permissions to an agent can determine which users can view, configure, and set security for that agent.
By modifying the Default Permissions and/or manually configuring additional permissions, you can fine tune what users are able to access which resource. Permissions are available for the following resource types (for workflows, see Setting Workflow Permissions):
General Resources. Users may be assigned Read, Write, Use, and/or Security permissions for the most commonly accessed resources:
| Agent | Distributed Server | Library Job (Configuration) | Project |
| Agent Relay | Environment | Library Workflow Definition | Repository |
| Artifact Set (see Securing Artifact Sets) | Environment Group | Life-Cycle Model | Script Group |
| Codestation Project | Folder |
System Resources. AnthillPro provides security around System resources that only select groups of users need access to. The following resources typically require Read and Security permissions for administrators in order to configure/edit settings:
System Functions. A user must have system permissions to act as administrator of the system-level functions listed below. Read or Security permissions provides a user access to the System page. A user may be assigned permissions to the following System Function resources:
| Administration | Integration Administration | Report Administration | Script Administration |
| Agent Administration | Life-Cycle Model Administration | Reporting | Security Administration |
| Auditing | Notification Administration | Repository Administration | Server Administration |
| Delete Runtime History | Prioritize Workflows | Restart Workflows | Stamp Administration |
| Environment Administration | Project Administration | Schedule Administration | System Administration |
When a new resource is created, it is automatically assigned Default Permissions by the AnthillPro system. You can modify these default permissions by following the procedures outlined in the Assign Additional Permissions section (i.e., editing the Default Permissions section of the resource). As a rule, the Default Permissions should allow most users within a role to perform their work. If you are frequently assigning additional permissions to a role, consider changing the default permissions for newly created resources.
Please note that changes made to the default permissions will only effect new, and not existing, settings.
When a new resource type is created, it is automatically assigned the predefined Default Permissions (see Configure Default Permissions). For most users, the Default Permissions should be adequate. But there are circumstances in which a small subset of users will need different/additional permissions to a resource. If this is the case, manually setting permissions by resource type is necessary. For example, the default permissions for the "User" role does not allow people to perform "write" tasks for a Codestation project. However, these users must occasionally update a third-party library. In this case, you can simply select Codestation Project from the Resource Type menu, find the project in the list, and add the write permission to the appropriate role.
Go to System > Permissions under the Security menu.
Select a Resource Type from the drop-down menu and click Set.
Select the Role from the Add Permission drop-down menu to add the read, write, and/or security actions that role can perform on the resource.
If you are changing the Default Permissions, please see Configure Default Permissions for more.
To remove a role from performing an action click the delete icon under the Roles menu.
Click Add the Done.
Workflows have their own permissions, different from other resources, but are configured like the other permission types (see Assign Additional Permissions). Users tasked with running either an originating, operational, and/or secondary workflow must have at least execute permissions to the workflow(s). In addition, that user must have access to the environment(s) and/or agent(s) used by they project(s) they execute workflow for.
Workflows have the following permissions you can assign to them:
Execute. Allows a user to run a particular workflow. Anyone with access to execute a build workflow must have at least read permissions. If the user must run a secondary workflow in a different environment, that user must also be assigned at least "use" permissions to the target environment(s).
Task Execute. Allows the user to perform the same actions as the execute permission, but only through the Task interface. Note that the "task execute" permission does not allow users to manually run a secondary process, etc., and gives them no system permissions. This is useful in situations where AnthillPro users are only tasked with deploying, but not building, a project or workflow.
Security. Allows a user to change the resource’s security settings.
For most users, the Default Permissions (see Configure Default Permissions) should be adequate. But there are circumstances when a small subset of users will need different permissions to a workflow. In this case, you can manually assign additional permissions. For example, the default permissions for the "User" role do not allow people to execute a deployment (secondary) workflow. However, you have one project in which you want these people to run a deployment using the Task interface. In this case, you can simply select workflow from the Resource Type menu, find the deployment workflow in the list, and add the Task Execute permission to the appropriate role.
Authorization Realms are used by Authentication Realms to associate Users with Roles and to determine user access to AnthillPro. Authorization Realms can be deactivated by clicking the Mark as Inactive icon (see below).
There are three Authorization Realm options:
Anthill. Uses internal Anthill role management. See Anthill Authorization Realm.
LDAP. Uses external LDAP role management. See LDAP Authorization Realm.
Single Sign-On. Uses external Single Sign-On role management. See Single Sign-On Authorization Realm.
The Anthill Authorization Realm uses AnthillPro to manage Users. You will need access to the System page in order to manage security.
Go to System > Authorization under the Security menu.
On the Authorization tab, click the Create Authorization Realm button.
Check Anthill, click Set, and configure Realm.
Name the Authorization Realm.
Description. Provide a description of the Authorization Realm.
If not adding an initial User Role, Click Save then Done to complete. Otherwise proceed to item 5.
Click the Add Initial User Role button (optional).
New users created within an Authentication Realm governed by the Authorization Realm you are configuring will automatically become members of the Roles configured here. For example, if a user is added to the Kerberos Authentication Realm that is managed by the Anthill Authorization Realm, the new user will be automatically assigned the Roles chosen here.
This item requires that the appropriate Roles have already been created. See Define Roles.
Select the Role from the drop-down menu and click Add Role.
To add more User Roles, repeat items 5 and 6.
Click Save then Done.
The LDAP Authorization Realm uses an external LDAP server for authorization. If User Roles are defined in LDAP as an attribute of the User, the LDAP Role Attribute configuration must be used. If User Roles are defined elsewhere in LDAP and reference the Users that belong to them, a LDAP Role Search needs to be performed. You will need access to the System page in order to manage security.
Go to System > Authorization under the Security menu.
On the Authorization tab, click the Create Authorization Realm button.
Check LDAP and click Set.
On the Main tab, configure Realm:
Name the Authorization Realm.
Description. Provide a description of the Authorization Realm.
Role Attribute. Give the name of the attribute that contains role names in the user directory entry.
If User Roles are defined in LDAP as an attribute of the User, the Role Attribute configuration must be used.
Role Name. Provide the name of the entry that contains the user's role names in the directory entries returned by the role search. If this is not specified, no role search will take place.
If User Roles are defined elsewhere in LDAP and reference the Users that belong to them, a Role Search needs to be performed.
Role Base. Give the base directory to execute role searches in (e.g., ou=groups,dc=anthill3,dc=com).
Role Search. Provide the LDAP filter expression to use when searching for user role entries. The user name will be put in place of {1} in the search pattern and the full user DN will be put in place of {0} (e.g., member={0}).
Search Role Subtree. Check True to search the subtree for the roles or False to not search.
If not mapping LDAP roles to Anthill Security Roles, click Save then Done to complete. Otherwise proceed to item 6.
Select the Role Mapping tab (optional) and follow the Map LDAP Role link.
This item requires that the appropriate Roles have already been created. See Define Roles.
LDAP Role Name. Give the LDAP role to map.
Anthill Role. Select the Anthill role to map the LDAP role to.
Click Save then Done.
The Single Sign-On Authorization Realm uses an external Single Sign-On server for authorization. You will need access to the System page in order to manage security.
| For authorization to complete, you will need to add the AnthillPro ROOT URL to your Single Sign-On authorization server. |
Go to System > Authorization under the Security menu.
On the Authorization tab, click the Create Authorization Realm button.
Check Single Sign-On and click Set.
On the Main tab, configure Realm:
Name the Authorization Realm.
Description. Provide a description of the Authorization Realm.
Roles Header Name. Enter the name of the HTTP header that contains a comma delimited list of Single Sign-On roles.
Click Save.
If not mapping Single Sign-On roles to Anthill Security Roles, click Done to complete. Otherwise proceed to item 7.
Select the Role Mapping tab and follow the Map Single Sign-On Role link.
This item requires that the appropriate AnthillPro Roles have already been created. See Define Roles.
Give the Single Sign-On role to map.
Select the AnthillPro role to map the Single Sign-On role to.
Click Save then Done.
Create and edit Authentication Realms to determine a users identity within an Authorization Realm. The User authentication is determined following the hierarchy of realms displayed on the Authentication tab. In the example below, authentication will first be determined in the System Realm, followed by LDAP and Anthill Realms, so a user listed in the LDAP realm may have different authorizations from those in the other realms.
| If you have a number of authentication realms, you can reorder them using the drag-and-drop tool so that the ones you are most interested in appear at the top of the list. Realms (except for the default Anthill realm) can also be activated or deactivated using the Operations menu. |
There are six Authentication Realm options:
Anthill. Uses AnthillPro to manage user authentication. See Anthill Authentication Realm.
Custom. Use this option to create your own authentication LoginModule. See Custom Authentication Realm.
Kerberos. External Kerberos user authentication using GSS-API. See Kerberos Authentication Realm.
LDAP. External LDAP integrated user authentication. See LDAP Authentication Realm.
RSA SecurID. External Single Sign-On user authentication. See RSA SecurID Authentication Realm.
Single Sign-On. External Single Sign-On user authentication. See Single Sign-On Authentication Realm.
You can add a second layer of security on the Secondary Authentication tab. Upon authentication in the primary Realms, Users are forwarded to this secondary Realm if they are a member of any Role requiring secondary authentication. See the Secondary Authentication item for the Authentication Realms you are using.
The Anthill Authentication Realm uses AnthillPro to internally manage users. You will need access to the System page in order to manage security.
Go to System > Authentication under the Security menu.
On the Authentication tab, click the Create Authentication Realm button.
Check Anthill and click Set.
On the Authentication tab, configure Realm:
Name the Authorization Realm.
Description. Provide a description of the Authorization Realm.
Authorization Realm. Select the Authorization Realm this Authentication Realm will use.
This item requires that the appropriate Authorization Realm has already been created. See Configure Authorization Realms.
If not setting a Secondary Authentication Realm, click Save then Done to complete. Otherwise proceed to item 6.
Select the Secondary Authentication tab (optional) and click the Create Secondary Authentication Realm button.
Upon authentication in the primary Realms, Users are forwarded to this secondary Realm if they are a member of any Roles which require it. The Secondary Authentication Realm adds a second layer of security.
This item requires that the appropriate Roles and Authorization Realms have already been created. See Define Roles and Configure Authorization Realms.
Check one of the available Authentication Realms and click Set.
Configure Secondary Authentication.
Authentication Settings will only take effect if the test login is successful (if test fails, a warning will appear).
Name the Secondary Authentication Realm.
Description. Provide a description of the Secondary Authentication Realm.
Test User Name. Give the user name to test the configuration with.
Test Passcode. Provide the passcode to test the configuration with.
Click Save then Done.
The Custom Authentication Realm uses a specified Java LoginModule to authenticate users. You will need access to the System page in order to manage security.
Go to System > Authentication under the Security menu.
On the Authentication tab, click the Create Authentication Realm button.
Check Custom, click Set.
On the Authentication tab, configure Realm:
Name the Authorization Realm.
Description. Provide a description of the Authorization Realm.
LoginModule Class. Give the class name of the Java LoginModule class to use (e.g., com.mycompany.security.loginmodule).
Authorization Realm. Select the Authorization Realm this Authentication Realm will use.
This item requires that the appropriate Authorization Realm has already been created. See Configure Authorization Realms.
If not setting a Secondary Authentication Realm, click Save then Done to complete. Otherwise proceed to item 6.
Select the Secondary Authentication tab (optional) and click the Create Secondary Authentication Realm button.
Upon authentication in the primary Realms, Users are forwarded to this secondary Realm if they are a member of any Roles which require it. The Secondary Authentication Realm adds a second layer of security.
This item requires that the appropriate Roles and Authorization Realms have already been created. See Define Roles and Configure Authorization Realms.
Check one of the available Authentication Realms and click Set.
Configure Secondary Authentication. Authentication Settings will only take effect if the test login is successful (if test fails, a warning will appear).
Name the Secondary Authentication Realm.
Description. Provide a description of the Secondary Authentication Realm.
Test User Name. Give the user name to test the configuration with.
Test Passcode. Provide the passcode to test the configuration with.
Click Save then Done.
The Kerberos Authentication Realm uses Kerberos to authenticate users. You will need access to the System page in order to manage security.
Go to System > Authentication under the Security menu.
On the Authentication tab, click the Create Authentication Realm button.
Check Kerberos and click Set.
On the Authentication tab, configure Realm:
Name the Authorization Realm.
Description. Provide a description of the Authorization Realm.
Conf File. Give the path to the Kerberos configuration file. On Unix and Linux, it is usually /etc/krb5.conf.
Authorization Realm. Select the Authorization Realm this Authentication Realm will use.
This item requires that the appropriate Authorization Realm has already been created. See Configure Authorization Realms.
If not setting a Secondary Authentication Realm, click Save then Done to complete. Otherwise proceed to item 6.
Select the Secondary Authentication tab (optional) and click the Create Secondary Authentication Realm button. The Secondary Authentication Realm adds a second layer of security.
Upon authentication in the primary Realms, Users are forwarded to this secondary Realm if they are a member of any Roles which require it.
This item requires that the appropriate Roles and Authorization Realms have already been created. See Define Roles and Configure Authorization Realms.
Check one of the available Authentication Realms and click Set.
Configure Secondary Authentication. Authentication Settings will only take effect if the test login is successful (if test fails, a warning will appear).
Name the Secondary Authentication Realm.
Description. Provide a description of the Secondary Authentication Realm.
Test User Name. Give the user name to test the configuration with.
Test Passcode. Provide the passcode to test the configuration with.
Click Save then Done.
The LDAP Authentication Realm uses an external LDAP server for authentication. You will need access to the System page in order to manage security.
If you plan on using SSL, please see Using LDAP over SSL with Self-signed Certificate below before continuing.
Go to System > Authentication under the Security menu.
On the Authentication tab, click the Create Authentication Realm button.
Check LDAP and click Set.
On the Authentication page, configure the following:
Name the Authorization Realm.
Description. Provide a description of the Authorization Realm.
Authorization Realm. Select the Authorization Realm this Authentication Realm will use.
This item requires that the appropriate Authorization Realm has already been created. See Configure Authorization Realms.
Context Factory. Give the context factory class used to connect. This may vary depending upon your specific Java implementation. The default for Sun Java implementations: com.sun.jndi.ldap.LdapCtxFactory.
LDAP URL. Provide the full URL to the LDAP server, beginning with ldap:// (e.g., ldap://ldap.mydomain.com:389). If using SSL, please see Using LDAP over SSL with Self-signed Certificate.
If your LDAP users exist in a single directory, select the button and give the following (otherwise, go to the next step):
User Pattern. Give the user directory entry pattern. The user name will be put in place of {0} in the pattern (e.g., cn={0},ou=employees,dc=anthill3,dc=com).
If your LDAP Users exist in many directories AnthillPro will have to perform a User search with the username. To enalbe this, give the following:
User Base. Give the user base directory to search for users in (e.g., ou=employees,dc=anthill3,dc=com).
User Search. Provide the LDAP filter expression to use when searching for a user's directory entry. The user name will be put in place of {0} in the search pattern (e.g., uid={0}).
Search User Subtree. If the LDAP User Names are case sensitive, check True to have AnthillPro treat different-case User Names as different Users or False to ignore.
Check the box if no anonymous access is allowed. If you are unable to access the LDAP server anonymously, you can use the Connection Name and Connection Password. Give the following (as above):
Connection Name. Give the directory name to use when binding to the LDAP for searches (e.g., cn=Manager,dc=anthill3,dc=com). If not specified, an anonymous connection will be made. Connection Name is required if the LDAP server cannot be anonymously accessed.
Connection Password. Provide the password to use when binding to the LDAP for searches. Required if Connection Name is specified. Connection Password is required if the LDAP server cannot be anonymously accessed.
Complete basic configuration:
Case Sensitive User Names. If you have case-sensitive user names (e.g., the user Bob is different than the use bob), select true. Otherwise, select false.
First Name. To read information from the LDAP entry, give the name of the user's LDAP entry attribute that contains the first name.
Last Name. To read information from the LDAP entry, provide the name of the user's LDAP entry attribute that contains the last name.
Email. To read information from the LDAP entry, give the name of the user's LDAP entry attribute that contains the email address.
XMPP ID. To read information from the LDAP entry, give he name of the user's LDAP entry attribute that contains the XMPP / Jabber IM ID.
MSN ID. To read information from the LDAP entry, give he name of the user's LDAP entry attribute that contains the MSN IM ID.
If not setting User Filters, click Save then Done to complete. Otherwise configure the User Filters to allow or block LDAP user from access to AnthillPro:
Allowed Patterns. Enter line-separated regular expressions of LDAP user names that will explicitly be allowed to log in to Anthill. Leave empty to not allow all users.
Blocked Patterns. Enter line-separated regular expressions of LDAP user names that will explicitly be blocked from logging in to Anthill. Leave empty to not block user explicitly. Blocked Patterns will override Allowed Patterns.
Test the configuration (required).
Test User Name. Give the user name to test the configuration with. When you click "Save" AnthillPro will verify the configuration. You will be unable to use the integration until this test passes. This can be any user in LDAP.
Test Password. Give the password for user (given above) to test the configuration with. When you click "Save" AnthillPro will verify the configuration. You will be unable to use the integration until this test passes. This can be for any user in LDAP.
Click Save then Done if the test passes.
If you are using LDAP over SSL with a self-signed certificate you will need to import the LDAP certificate to the Java Virtual Machine that AnthillPro runs on. Typically, you can do this in one of two ways:
Use a Java KeyStore. This relies on the Java key manager to supply keys to others as needed, e.g., for use in authenticating the user to others. If you are unfamiliar with Java KeyStores, please see the Java documentation.
Ensure the certificate version can be imported to the JavaVM KeyStore. If the certificate does not import correctly, the integration will fail.
You can verify that the import was successful using other Java-based applications. For example, JXPlorer can be helpful.
Use a Java TrustStore. Relies on the trust manager to makes decisions about who to trust based on information in the TrustStore. If you are unfamiliar with Java TrustStores, please see the Java documentation.
Ensure the certificate version can be imported to the JavaVM TrustStore. If the certificate does not import correctly, the integration will fail.
The certificate must be placed in a directory that
AnthillPro can access. Once this is done, the location needs to be
added to the ah3server start script as
follows:
JAVA_OPTS parameter. Use the following
parameter with the absolute path to certificate location:
-Djavax.net.ssl.trustStore=/point/to/your/certificate/file.
You will need to restart AnthillPro for the changes to take effect.
You will also need to use the appropriate LDAP URL syntax (e.g.,
ldaps://myldap.server.com:636) when configuring the LDAP
Authentication Realm integration.
The RSA SecurID Realm uses the RSA SecurID token-based system to manage users. You will need access to the System page in order to manage security.
Go to System > Authentication under the Security menu.
On the Authentication tab, click the Create Authentication Realm button.
Check RSA SecurID and click Set.
On the Authentication tab, configure Realm:
Name the Authorization Realm.
Description. Provide a description of the Authorization Realm.
Authorization Realm. Select the Authorization Realm this Authentication Realm will use.
This item requires that the appropriate Authorization Realm has already been created. See Configure Authorization Realms.
If not setting a Secondary Authentication Realm, click Save then Done to complete. Otherwise proceed to item 6.
Select the Secondary Authentication tab (optional) and click the Create Secondary Authentication Realm button.
Upon authentication in the primary Realms, Users are forwarded to this secondary Realm if they are a member of any Roles which require it. The Secondary Authentication Realm adds a second layer of security.
This item requires that the appropriate Roles and Authorization Realms have already been created. See Define Roles and Configure Authorization Realms.
Check one of the available Authentication Realms and click Set.
Configure Secondary Authentication. Authentication Settings will only take effect if the test login is successful (if test fails, a warning will appear).
Name the Secondary Authentication Realm.
Description. Provide a description of the Secondary Authentication Realm.
Test User Name. Give the user name to test the configuration with.
Test Passcode. Provide the passcode to test the configuration with.
Click Save then Done.
The Single Sign-On Authentication Realm relies on a external single sign-on server to handle authentication. Before you can configure authentication, ensure that the appropriate Authorization Realm has been created.
You will need access to the System page in order to manage security.
Go to System > Authentication under the Security menu.
On the Authentication tab, click the Create Authentication Realm button.
Check Single Sign-On and click Set.
On the Authentication tab, configure Realm:
Name the Authorization Realm.
Description. Provide a description of the Authorization Realm.
User Header Name. Give the name of the HTTP header that contains the Single Sign-On user name.
Logout URL. Enter the URL a user is redirected to when they logout of AnthillPro.
Authorization Realm. Select the Authorization Realm this Authentication Realm will use. If you configured the Single Sign-On Authorization Realm, select from the drop-down. Or, you can use a different tool for Authorization: e.g., the built-in AnthillPro authorization system.
Click Save then Done.
Users are added to the Authentication Realm. Once a user account is activated, AnthillPro users may edit some of the settings configured below (by following the profile link at the top of their browser window). If a user changes his/her contact information or password, AnthillPro will automatically update the changes. See Configure User Profile.
You will need access to the System page in order to manage security.
Go to System > Users under the Security menu. On the Users tab, choose the Authentication Realm from the drop-down menu. Click Set.
If integrating AnthillPro with LDAP, see Configure Authentication Realms. Once configured with LDAP, AnthillPro will utilize users from the LDAP Authentication Realm.
Click the Create User button. Give the user a name, set and confirm a password, and check which roles the user will have. Click Save.
Identify the individual user.
Name. Give the name the user will use for log in. Once this is set, individual users will not be able to change the Name. See Configure User Profile.
Roles. Check the roles this user is assigned to. A user's role determines which Anthill features and projects will be available to them. A new user is automatically given the "user" role. See Defining Roles.
First Name. Provide the user's first name.
Last Name. Give the user's last name.
Email Address. Provide the user's e-mail address.
XMPP ID. If using Jabber, Google Talk, etc., enter the ID where the user will receive notifications from Anthill3. See Configure Instant Messaging.
MSN ID. If using MSN IM, enter the ID where the user will receive notifications from Anthill3. See Configure Instant Messaging.
Time Zone. Select the time zone the user is in.
Number of Dashboard Rows. Give the number of recent build to include on the user's dashboard.
Click Save.
To add a new alias, click the User-Repository Alias button. Select the appropriate repository from the drop-down menu and give the user’s alias used in that repository. Click the Add User-Repository Alias button to finish.
Any source-control user names belonging to this user (i.e., New User) can be mapped in the User-Repository Alias section. If this is done, AnthillPro will then map the changes this user makes. For example, this allows you to only send notifications to those who committed on a certain build, or to those tracking changes and users over time. A mapping is not needed if the source control name is identical to the AnthillPro user name.
Once created, a User-Repository Alias may not be edited. If a user name for a repository has changed, delete the current alias (click the Remove icon under the Operations menu) and create a new one.
Click Done.