I like to think that I am unique. However, to my IT, security and identity teams, I am just a mix of sales, marketing, management and location roles. Knowing those four things about me can generally define what system access I will need.
A properly built Identity & Access Management (IAM) infrastructure can determine which of these roles I am in dynamically based on attributes in my HRIS, Active Directory, and other identity stores. For external users, the source of truth might be CRM or your supply chain identity store. These attributes are everywhere and can easily be synchronized into a metadirectory like EmpowerID's that utilizes a hub and spoke model, giving you a full 360 degree view of all of your users' information.
Once you know everything about your users and the role(s) that they have, what are you going to do about it? Provision user accounts! Remember those four roles that define me? Those also define what user accounts that I should have.
My "person object" or "identity" in the metadirectory includes the role definitions and role based provisioning rules to provision these accounts. It sees "sales manager in California" and knows that I need SalesForce, GoToMeeting, a soft phone and Dynamics AX accounts. EmpowerID will provision these accounts and then link them to my "person object". Once I no longer satisfy the conditions for having that role, my user accounts (not my identity) are de-provisioned.
Having a connector to each application allows the metadirectory to also inventory that application to determine if any changes are made natively. If it finds a new GoToMeeting account that is not linked to an person object, it will evaluate "join rules" to join this account (or de-activate it if you want to discourage or deny native access). If there is no person object to join it to, it will become an orphaned account and the appropriate admin will be notified.
This role based provisioning is exceptionally important for external users such as contractors or suppliers or customers. All of these users are more temporal, coming and going more frequently. If a supplier needs access to your Ariba procurement network, you want to give a lifecycle to that account, ensuring that somebody certifies or attests to the account. Let's say for example that the procurement role needs to attest, perhaps you want to do a runtime check to see who the supplier's account manager is and only have them responsible. This Attribute Based Access Control (ABAC) method keeps you from having too many roles while still giving fine grained permissions around either the initial approval or attestation of a new account.
As you are designing these role based user provisioning rules, you are probably mapping them on a whiteboard. EmpowerID's visual workflow platform actually allows you to drag and drop shapes (identity actions such as provision account, go for approval, etc) exactly as you are drawing it. Though it is most likely more colorful and exciting in EmpowerID!
Don't get stuck with user provisioning that doesn't take into account who your users are. And certainly don't get stuck with a limited level of roles and identity sources. Because even though every user can be defined by their roles, they are still most likely a unique blend of multiple roles. Your user provisioning process should reflect that.
Read how EmpowerID's unique RBAC and ABAC hybrid model gives you more finely grained control over all things roles: from authorization to authentication to provisioning.
