FlexDeploy provides its own proprietary repository for managing security, including users, groups, and permissions. The implementation provides a fine-grained permission model so that groups can be configured to match the roles and responsibilities of any organization. FlexDeploy also supports LDAP and Active Directory integration for user authentication.

Security administration is restricted to FlexDeploy Administrators only.

Security Administration

See authentication and authorization summary details below for quick reference.

Authentication

You can configure users in FlexDeploy internal realm or use external LDAP server.

See Users to maintain users in FlexDeploy internal realm. If you use this option then you are not relying on external directory servers.
You can use Active Directory or other LDAP server for authentication and authorization, see Realms for reference. FlexDeploy user record will still be created when user from external LDAP server logs in for first time. See new user process on Realms page.
You can also use both internal as well external realm for users. Users will be first authenticated against external realms and if not successful internal realm will be used.

Authorization

In order to control access to various parts of FlexDeploy, you will be configuring permissions for FlexDeploy groups. FlexDeploy supports coarse and finer grained permissions, see below for details.

Permissions are mainly controlled using FlexDeploy Groups even when using external realm. When using external realm, you can map external directory groups to FlexDeploy groups. Group mapping allows for less security maintenance when new users start using FlexDeploy.

Use global permissions control access to various objects in FlexDeploy. Global permissions do not control access at individual item level but rather at entire object level, i.e. if you grant Create / Update access for Workflow to group, members of that group can create or update any workflow. See global permissions for FlexDeploy group.
Use deployment permissions to restrict available environments on deployment request form. See deployment permissions for FlexDeploy group. For example, if you want to restrict specific group of users from deploying environments other than development and test, then configure deployment permissions accordingly. Alternatively, you can allow for deployment to all environments and setup approvals using FlexDeploy approvals or external change management system approvals.
Finer grained permissions
1. Project - control access (read, create, configure, execute etc.) to specific projects for FlexDeploy groups. You can configure this for a project or folder. Configurations at folder level apply to all projects contained in it. See Project Security. This model allows for restricting configuration edits of projects to specific groups and still allow others to view and execute build / deploy on projects.
2. Release - control access (read, configure, execute etc.) to specific release for FlexDeploy groups. You can configure this using global permissions and override at specific release as necessary. See Release Security.
3. Pipeline - control access (abort, replay, skip etc.) on pipeline execution. Pipeline allows for abstraction in to roles that are mapped to FlexDeploy group and/or users. For example, developers, leaders, managers, operators etc. are some examples of pipeline roles. You can define permissions on each pipeline role. See Pipeline team security.

Browser not supported