Common challenges with PasswordSafe User Provisioning comes down to the confusion between Smart Rules and Smart Groups, and the concept that PasswordSafe groups are only provisioned if they have permissions assigned to them. You cannot give access to users who are in a group with no permissions. 

📌 If you’re wanting an overall yes/no flow if a user can access PasswordSafe or a managed account, please see Whiteboard Workflow Diagrams for PasswordSafe Authentication and Permissions | Community

In the effort to share the knowledge, I’m sharing the raw whiteboard notes I have around an approach to thinking about PasswordSafe User Provisioning. Whiteboards are my first step in understanding any system, and, quite frankly, I’ll never get this article posted if I were to transpose this into writing. 

🚩 This is a general case. There are different ways of altering what a user is provisioned to access by using the PasswordSafe configurations. 

PasswordSafe Users need a provisioned reason

PasswordSafe won’t allow users to log into the console unless they have provisions associated to a use case, even if they can authenticate against SAML and belong to a PasswordSafe user group. 

Smart Groups vs Smart Rules

PasswordSafe assigns roles to Smart Groups. The Smart Groups vs Smart Rules aren’t the same, and the following is a summary of the difference.

Provision a Smart Group that allows a WHO and WHAT 

Since you’re provisioning access to a Smart Group, this gives a general guide about how assigning a Managed Account Smart Group can provide both the WHO and WHAT with linking.

PasswordSafe Provisioning Diagram

The following is an example of how granting access to Smart Group A provides linking to the different systems.