Deployment of the Security Rules in Production
The VG WinConsole provides a Deployment module.
Developers use this module to deploy the Permissions and Roles related
to their application. When new versions of the application are released,
the deployment module automates the update of the permissions in the target
repositories (testing, QA, production…).
Fig 1 - Deploying a Repository
Visual Guard Deployment - Application Lifecycle
Visual Guard Automates the deployment of Security Data managed by developers during the application lifecycle. These data are merged with data created by administrators.
- Initial Deployment
Developers define Roles, Permission Sets and Permissions in the development repository.
They deploy them in the empty Production Repository.
- Daily IAM Management
Local Administrators create and manage user accounts and grant them with roles.
- Subsequent Deployments
Developers update the security data.
The updated data is merged to the data existing in the Production Repository.
How to organize and deploy the security data of an application?
This schema describes several possible combinations for an application deployed on a site where local Roles, Permissions and Permissions Sets are required.
More Information
- Developers define Roles, Permissions Sets and Permissions in the development repository and deploy them in the production Repository
- Local Admin may grant the Role “Operator1” to users, as defined by default in dev.repository.
They may also create Local Roles, Permissions Sets and Permissions.
A Local Role can contain a Global Permission Set.
A Local Permission Set can contain a Global Permission.
- When Permission B is added/edited, included in Permission Set 1 and deployed, both Roles “Operator1” and “Operator2” have this new permission in production.
- When the repository is deployed, Local Roles, Permission Sets and Permissions remain unchanged, as well as the relationship Permission Set 3 <containing> Permission Set 1.