All-In-One Identity Management and Cloud Security

Windows has created a false premise that the best way to manage shared folder permissions is with groups.  You grant access to the folder by way of an AD security group, then users request membership in that group.  That's the way NTFS works but is it the way users think?

Users want access to a resource; they want access to a folder.  They don't want membership in a group.  Of course, they need membership in a group, but they don't know that.  So, why would you force users to ask for access in such a roundabout way?  It should be simple and the mechanism of how it is happening in the background shouldn't matter to your user.  The premise is: users will think of what they want access to and should be able to request it directly.

EmpowerID File Share Manager puts a 360 degree view of file shares in front of your user.  They can view what roles and/or groups they are a member of and see the resultant access to shared folders.  Or they can view the shared folders they have access to and see the roles and or groups that make that happen.

And, most importantly, they can search on folders to request access.  When they request access a few things happen unbeknownst to them.  If they are allowed access directly, they are granted access.  If a resource owner needs to approve access, it will route the approval to the owner and let the user know that it needs an approval before granting access.

EmpowerID does this by putting a user into a role which has access to that resource (shared folder in this case).  By putting the user in a role and not an AD group it saves the user from being a member of too many groups and ultimately getting token bloat.  Token bloat seems like a made up malady but it is bad.  The more groups your user is in, the larger their token gets.  At 1015 memberships, the token exceeds allowable size and the user cannot log in.  As it gets over 256 memberships, authentication slows down and kerberos has a tendency to lock up with some applications.

So, by managing your shared folders with a dedicated self service portal, your users will have greater and easier access to shared folders, request access in a more intuitive manner, control harmful afflictions like token bloat, and reduce your dependence on an outdated technology like groups.

But you really don't stop there.  That same self service portal can be used by the resource owners to see who has access to their resources (even if granted via groups the old fashioned way).  They can grant and revoke access to their folders either by searching from the user or the resource.  Most importantly, they can attest to the correct access from the resource side on a regular scheduled basis to meet auditing requirements.

Speaking of our friends the auditors, they might be even more resource oriented than the users.  They need to track who has access to a resource and it costs you money and time to have them try to disentangle all of the resultant access from nested groups.  Having them look directly at the resource is, after all, what they need.

Think about the problem of groups from their perspective.  If a group is giving access to a shared folder, what happens if you're also using it for another purpose and people just keep getting added to it.  Your auditing friend wants to be able to see that easily.  EmpowerID solves that issue in another way, too. 

We use hidden system managed groups and use them in a way that maximally reduces token bloat.  The goal is to reduce the number of groups created to assign permissions and to completely control the membership of these groups so people can’t use them for other purposes and add members which would inadvertently grant access to the folders.  We reject any outside additions or deletions of user to these groups.

The debate has raged for years on groups vs. roles, especially with regard to Active Directory and Windows permissions.  The answer is easy: using groups is the old way; using roles is the new way.  Using groups is letting the technology manage the way you do business.  Using roles is making the way you do business lead the technology.  Especially with shared folder permissions.

What goes up must come down.  For every action there is an equal and opposite reaction.  Every user provisioned is eventually deprovisioned.  It's the circle of identity, a term I just made up.

At its core, the concept is simple.  In practice, it is a lot of work.  Microsoft published a statistic at one point that the average user is provisioned in 16 directories when hired yet only deprovisioned from 9 upon dismissal.  That is 7 directories worth of identity floating around your enterprise for a user that doesn't exist.

Provisioning has to be automated and deprovisioning has to be tied to that process.  The obvious automation that you need is to have both processes tied to your HR system.  The logic is simple, if you have a hire date and no fire date, you should have a user account.  But the flaw starts when you have multiple connected systems, both cloud and on-premise.

If you were hired as the receptionist, got promoted to a coordinator and ultimately a manager, you should and will have different accounts in different applications for each of those stages of your career.  Upon your termination date, your identity management system needs to know which accounts you currently have to properly deprovision you.

In effect, you need constantly updating role based provisioning to keep up with your ongoing provisioning and deprovisioning needs.  These roles will constantly update not only your resource access but your application access as well.  Think of it like a key ring, take the old ones away when you add new ones.  You are much less likely to have those extra 7 accounts on your last day.

To keep all of this in synch, your identity platform needs the concept of a person account which joins all of your user accounts to you.  EmpowerID's metadirectory performs this function giving a full view of all of a user's accounts tied to their person record.  So after the three promotions and constant turnover in that user's lifecycle, upon their termination date, you have a clear record of all application accounts, and can deprovision ALL of them, both on premise and cloud.

Think about this term: lifecycle.  Because not all users are managed by a set of hire/fire dates.  Contractors, temps, external partners, customers.  HR cannot be expected to keep a good record of the hire/fire dates of these users, yet they still need access.  Again, not just to the network but to individual applications.

The EmpowerID metadirectory allows you to put start and end dates on any access to any resource, keeping the access from living forever.  Upon hitting the end date, simply renew or let the access expire.  The same thing applies for attestation, you can have the owner of a resource attest to all users who need access.  Or you can have the owner of the identity (manager, account manager, etc) attest that the user still needs each level of access granted.

The metadirectory's join engine and provisioning and deprovisioning workflows automate provisioning and deprovisioning.  The attestation policies keep exceptions from slipping through the cracks.  This keeps the user account store from going up without going down.

If you want cloud SSO, you need cloud provisioning.  This isn't a brilliant revelation...your users can't log in to an account they don't have.

Let's take my favorite and most frequent use case: the wild world of Salesforce.com!  You want your users to be able to authenticate into salesforce without having to re-enter credentials or, worse yet, enter a completely different set of credentials.  So you federate with Salesforce.

Your user authenticates into the network using either her Active Directory or EmpowerID credentials.  She clicks on a link to salesforce and it quickly and invisibly redirects to the EmpowerID Secure Token Service which sends a SAML token to Salesforce which then accepts it and our intrepid user finds herself in Salesforce authenticated and ready to do work.  Without entering any additional passwords or user names.  Like magic, sweet federated magic.

The trick to this is your user needs a salesforce account.  And EmpowerID (or any other identity provider) needs to know what that user's account is.  Without automated cloud provisioning, do you manually provision each account?  Do you have each user claim their account to register it?  Do you put users in AD groups to establish access and hope against all hope that that group stays accurate?

Or do you integrate cloud provisioning with cloud SSO?  This way, users are provisioned and de-provisioned...automatically associating EmpowerID (or some other identity store) accounts with the Salesforce account?  Giving them the SSO experience when they should have it and removing that capability when they should not.  And, reducing the steps needed for users to get this capability.

So, what about existing users?  Do you have each user go and claim their account?  Users hate to follow IT instructions, we all know that.  So let's inventory salesforce.  All you need is a key (such as email address, conveniently your salesforce user name) and you can associate each of your corporate accounts to their salesforce accounts.

And the result, cloud SSO.  And made all the easier because of the connection between cloud SSO and cloud provisioning.  I have written extensively about this, about the connection between all aspects of identity and access management.  You need your provisioning to interact with your access governance to interact with your authentication to interact with your password management. 

IAM is a complex beast to slay, especially with the newer cloud aspects of today's world.  Having a complete platform that can be implemented in phases but still work together solves this and makes this beast much more manageable.

Let's start with the cloud.  Let's get your cloud SSO and your cloud provisioning working together.  Take a look at the federated SSO whitepaper and then schedule a demonstration of how EmpowerID will get your users provisioned and SSO'd to the cloud.

The average user in a medium to large enterprise has 16 applications that they need to access to do their job.  This means 16 username / password combinations.  Doing the math, this translates to a metric boatload of help desk calls to support this many passwords.

There are three things you can do about this:

1. Provide single sign on (SSO)
2. Provide self service password reset
3. Synchronize passwords between the applications

There are advantages and limitations to each option.  Single sign on is probably the best solution, having your users log in once and then be authenticated into each application.  However, if the application doesn't support federation, you will need to do password vaulting and you still have the problem of a lot of passwords.  Many legacy systems will have this limitation.

Providing self service password reset is also a great option.  It allows you to delegate changing passwords once forgotten and can have built in security like two factor authentication or forced enrollment.  But, you're supporting 16 applications and you might as well fix the problem before the horse leaves the barn.

That brings us to password synchronization.  You will give your user a single password that is the same for each application.  When they change it in one place (for example, Active Directory), it will be synchronized to each application.  Users will still need to enter a password each time, but they only have to remember 1 not 16.

Before I go any further, the same EmpowerID module for password synchronization also provides self service password reset, giving you option 2 & 3 in one fell swoop.  Since EmpowerID is a single code-base platform, EmpowerID SSO Manager also can work in conjunction with Password Manager to provide all three options to work together.

EmpowerID is a hub and spoke model, with a metadirectory sitting squarely in the middle keeping identity data and passwords synchronized.  You will most likely have a source of truth for the password, whether it be the EmpowerID directory or Active Directory.  Once this password is changed, EmpowerID will write out that password to all affected applications using stored procedures or APIs. 

If there are different password complexity requirements, EmpowerID can enforce the most restrictive and ensure that the user has a single password for all applications.  If there are mutually exclusive password policies (no special characters in one but special characters required in another, we should explore single sign on).

The first question is usually, what starts this process?  How can you synchronize a password if it is encrypted in the source of truth directory?  We can't, nobody can.  We need to force the synchronization process to start by changing the password initially.  Once EmpowerID has the password, we can follow the security guidelines of each application to synchronize the new password to these 16 applications.

The simplest way to do this is to force the user to change their password on the next login, whether it is to EmpowerID or to Active Directory.  This setting is easy to turn on and gives the user an easy way to create the new synchronized password.  We can also build the password change action into any authentication workflow or give them the requirement to change the password x days before expiration.

But we haven't really saved IT a lot of time yet unless it's easy to implement and configure.  That's where EmpowerID's visual workflow comes in.  Every identity action your users take goes through a workflow which can be customized and personalized.  For our password example, this means that for users with more highly privileged access can be forced to change passwords more often or to also need two factor authentication with OATH tokens. 

This workflow maps to your business process and gives you flexibility in how you manage your passwords and users, giving different policies for different roles or applications.  In short, it makes password management flexible.

But once the users have a single password, the metric boatload of time saved by IT can go towards the single sign on (SSO) project you've been looking at. 

Prior to The Dot Net Factory, I spent over six years helping healthcare organizations implement software solutions.  During that time I helped doctors, frontline care workers, financial staff, even maintence staff to replace paper documentation systems with electronic documentation solutions.  Now my time in Identity & Access Management (IAM) has helped me to bridge the gap between healthcare and IAM.  Here is a list of common complaints that I heard in the healthcare world:

• Why do I need another system to log into or remember a password?
• Who will setup the permissions for the solution – with HIPAA requirements they must be accurate and up to date?
• What if I am locked out and I need access now?

Another Password or Another Sign in!

As a healthcare professional your job first and foremost is to care for your patients, individuals, & residents.  This means that making sure that Sally gets her medications is your first priority but unfortunately if it doesn’t get documented then it didn’t happen which can setup you up for a costly error that can mean legal or survey errors in the future.  Then what if you need to check her blood pressure before giving the medications and that needs to be input to a vital system?  Now we have two systems that need to be accessed to input one interaction with a patient. 

Enter – SSO (single sign on), now staff can log into Windows, an EHR, or any other trusted app once and then EmpowerID handles the heavy lifting of making sure everyone get access to all of the apps you need without logging in again.

Providing the Right Access

You are a complicated healthcare entity.  You may have a doctor’s office, skilled nursing homes, a hospital, or you provide home healthcare.  You could also be one entity with several wings or units.  Your staff needs access to only what they need and nothing more in every system to avoid HIPPA concerns. 

EmpowerID's Role Based Access Control (RBAC) engine can pull from your HR system to assign the right access to the right people because we know that Sally is a Nurse Supervisor on the Alzheimer’s unit.  Those two things tell us who she manages, what she controls, and what she needs access to.  Your healthcare apps already filter by service location or healthcare unit.  Wouldn’t it be nice to have EmpowerID put them into the correct place at the correct time? 

Access Now!

Your patient is complaining of extreme pain and we must move him from outpatient service to the emergency room, now!  You are ready to take him but you know his daughter was in just earlier today and she needs to be contacted. You need to access your patient’s emergency contact information to see his daughter’s contact information and right as you go to access it you realize that you ignored your email that said your password would expire about 10 minutes ago (of all the moments). 

This particular app doesn’t support self-service password reset  so you have to submit a ticket or call the help desk to get access.  Or even worse you know a friends password or you can have your friend access the information for you (even though it is your patient and not his!).  With EmpowerID’s Password Manager we can give you the tools to reset the password on the fly.  And if you reset your password once it will push the change to all of your apps.  You will answer a series of questions that only you know the answer to; the best part is that EmpowerID can force you to enroll in the password reset system..  This ensures that when you are in this bind you are setup to take care of it quickly. 

These are only a few scenarios but Healthcare systems require so much complicated access and are used so frequently and with so much urgency that access has to be easy on your workers.  Anything from clocking in through one app to giving patients access to their health record from another app or accessing a client’s medication allergies makes things more of a challenge.  That is why our full IAM suite allows you to address one issue or all of them through one platform.

For years I've been engaged in the debate over using SharePoint or Active Directory groups for SharePoint permissions.  There are pros and cons to each and I am pretty sure there is no perfect answer to which is better.  However, I am pretty sure that role based access control to SharePoint solves the issues with both types of groups.

Here's why: you don't get token bloat with roles, you can create dynamic roles, you can run self service workflows for users to join roles, you can delegate role membership management to users, and you can use the roles for almost any other identity action.

EmpowerID makes role based SharePoint permissions possible by being a SharePoint Claims Provider for SharePoint 2010.  As the identity provider for SharePoint, EmpowerID will pass a token that has all of a user's claims including both authentication and authorization.  This means a user is authenticated into your network and navigates to a SharePoint site; SharePoint will check with EmpowerID to see if that user exists and what access she has.

Using WS-Federation, EmpowerID's Secure Token Service sends a token to SharePoint to authenticate that user.  In addition, any additional authorization claims are embedded into the token so that the user has access to all of the sites that she should.

As the claims provider for SharePoint, EmpowerID's roles are inserted into the people picker for site owners to provide access.  They see these roles right next to users and groups.  If an end user wants access to a site, they can request access and EmpowerID can assign them to a role (depending on approval levels of course).

That's how it works but the magic is in defining the roles for the user.  EmpowerID roles can be managed dynamically or delegated.  The majority of roles are going to be based on our polyarchical system and dynamic.  If you are in XYZ department in ABC location, you are in the XYZ role, the ABC role, and consequently the XYZ-ABC role.  This keeps the number of roles from getting bloated, having to create one for each management role/location combination.  These management roles can be based on any criteria: business unit, department, title, whatever fits your business.

Users can also request role membership.  The EmpowerID workflows to make this happen can require varying levels of approvals based on who is requesting and what they are requesting.  Some are automatic (book club member) some are severely restricted (earnings committee).  The self service interface can be via EmpowerID or exposed in SharePoint.

Lastly, each role has an owner or owners who can manage the membership, either for approvals or to directly manipulate the membership of the role.  Any role membership can be attested to, can be made temporary, or can require approvals.

Back to the SharePoint site owner, she doesn't have to worry about the membership of the roles.  The three methods above of managing membership means that she just has to worry about which role should have access.  Remember SharePoint groups are static and require manual intervention.  AD groups' membership cannot be viewed in SharePoint so the site owner has no idea who she just granted access to.  Each of these concerns is addressed with an EmpowerID role.

SharePoint is an invaluable tool for your business but managing it from within IT is burdensome.  Too often, SharePoint is configured and accurate on day one and the permissions slowly deteriorate as site owners manage access manually.  Fix this for them.  Manage roles for your entire identity ecosystem and provide these roles to site owners to manage their site's access.

EmpowerID's standards based approach will give you SSO and role based SharePoint permissions.  It is easy to manage and even easier once you start delegating.  Your SharePoint implementation will become more robust and useful.  Schedule an EmpowerID demonstration and see for yourself how your life can be easier.

Security is not easy.  IT's goal is to find a way to increase security without adding complexity to the point where it reduces productivity.  It is a fine line and one that needs constant balancing.

Authentication is a key point on this security balance beam.  Password complexity, multi factor authentication, adaptive authentication, federation and single sign on are all considerations in how to deliver security without hindering productivity. 

Starting on one end of the spectrum (no security but easy for users) is a simple eight character password synchronized to all of your applications....that is not good.  On the other end of the spectrum you can have each application having a separate complex 16 character password with biometrics and identity proofing and an OATH token....your users will kill you.

I believe that targeted two factor authentication with single sign on is the answer.  Adaptive authentication is what makes this work.  Because EmpowerID is built on a visual business process oriented workflow platform, you can insert additional authentication options into any workflow based on either the role of the user authenticating or based on the application that the user is tying to access.

Examples of these two options are:

• Adaptive authentication based on the user's role: All users should be able to authenticate into the network with a password but more highly privileged users (domain admins or VPs of finance) should have a higher level of security.  These users will be placed into a role or group that requires a second authentication factor such as an OATH token.  (note: I find it very interesting that those with the highest level of access tend to be those who can control their authentication level such as CxOs or domain admins)
• Adaptive authentication based on application:  This option will result in much less resistance and one could argue is actually more secure.  When a user tries to access a more highly sensitive application or resource, the EmpowerID workflow will recognize the resource as security level X and apply a more stringent authentication method such as knowledge based questions or an OATH token.

The key to all of this is that the IAM platform must have workflows that can increase authentication levels based on either the user's role or the resource's security level.  EmpowerID's visual workflow can even make a hybrid model of this where certain roles accessing certain resources can trigger the advanced authentication.

It is also crucial to use the correct second factor.  As you know, the first factor is what you know and the second factor is what you have and the third factor is what you are.  Remember that balancing act between security and productivity?  The productivity side also incorporates how hard it is to get the second factor into your users' hands.

How hard is it to get iris scans or fingerprints for every user?  How hard is it to deploy smart cards for remote users when you have a 5% turnover per year?  How difficult is it to manage physical assets to manage the "what your users have" factor?

This is what makes smart phones so darned valuable.  Everyone has one.  The flip side to the BYOD revolution is the first three letters: users bring their own!  You can take advantage of this by having users register their devices as part of the authentication (yes, EmpowerID can do that for you).  Then either text a code or demand an OATH token as the second factor.

There are plenty of open source apps available (for example, this one for the iPhone) for the OATH client so you don't even have to deploy hardware.  EmpowerID has its own OATH server, creating a simple seamless way to incorporate an open standard such as OATH and the widely available smart phone from your users to create a very flexible adaptive authentication method using two factor authentication.

And you get to balance productivity and security by selectively applying this second factor to highly secure and confidential resources and highly privileged users.  Additional security without sacrificing productivity.  Schedule a demonstration of EmpowerID and see how we can make that a reality for you.

Identity and access management (IAM) is a big concept.  Google analytics tells me that there are 18,100 searches for this term each and every month.  Gartner's definition is that "IAM ensures the right people have the right access to the right resources at the right time, enabling the right business outcomes."  That is a big concept.

However, it is rare that an organization is trying to solve every single aspect of IAM in a single project.  Some do and EmpowerID can do it.  But most don't and they need a modular approach to solving the IAM problem. 

To break down Gartner's definition:

• The right people: user provisioning into the metadirectory and all applications
• The right access: attribute and role based access control
• The right resources: inventorying of protected resources whether they be applications or files or anything
• The right time: workflow that ensures that all actors (people, roles, resources) are updated at all times
• The right business outcome: a workflow model that corresponds to your actual business process

The best and easiest example is a client who comes to us looking to solve its user provisioning problem (the right people).  EmpowerID does this in its sleep (just kidding, EmpowerID doesn't sleep).  The EmpowerID metadirectory constantly inventories all connected applications and identity stores, updating information and flowing it between any directory or database that needs the information. 

A user is provisioned in HR, gets an EmpowerID person account which then creates application accounts based on the user's role.  As soon as that user is changed in any connected application, that identity information flows througout the identity stores associated with that user.  As their role changes, their permissions change and their access changes.  Once the user leaves the organization, the user is de-provisioned.

As you can see, this quickly leaks beyond the right people to the right access.  And the right resources.  Yet not all products can accomplish this from a single platform, much less one with a single code base.  EmpowerID can.  And we haven't even gotten into what comes next.

User provisioning is a very common use case.  Very common.  What happens next is also common, we ask, "what about single sign on?"  Invariably, the client says something along the lines that they are looking to solve that next fiscal year.  Then we say, "what about your extranet, do you want to manage external identities?"  Just as often the answer is something along the lines of another team has a concurrent project for that.

And this is where having an actual identity management platform comes into play.  EmpowerID can solve the current project's business dilemma and future proof for the additional business problems.  The integrated metadirectory, roles engine and visual workflow platform allow all of the modules to work idependently or in conjunction to solve additional problems.

In the first SSO example, once the users are provisioned and synchronized and you know your identities are accurate, it is simple to base the applications that they can access on the role of these users (remember, you already have that in place).  Just adding a few single sign on workflows opens up the possibility for adaptive authentication based on resource or role.

You can easily incorporate partners and customers into the fold for the second example.  EmpowerID is designed for multi-tenancy so you can even have different customers have different levels of access.  Your roles are in place for your end users so it's easy to give permissions to employees to manage the customer's access and identities.

All of it works together without the need to buy everything at the time of the original project.  One of our more recent customers, a large publishing house, took this exact approach.  Their initial aim was user provisioning and access governance.  Basically, get their own house in order.  The next step is the customer portal, giving end users and book stores role based access to online ordering and account management.  The third phase is getting internal user's access to this customer portal and all of the legacy systems.

Basically, they future proofed their Identity & Access Management on top of their initial project's requirements.  This is an important ability to check when deciding on something as big as your IAM vendor, it's a lot more than just synchronizing some attributes back and forth; it's matching your business processes (now and in the future) to your IAM workflows. 

Schedule a demonstration and see how we can map what you need to what we do and be prepared to think in the future when we ask you what's next.

Believe it or not, we federate every single day in the real world.  The whole concept of federation is that a "service provider" trusts the "identity provider".  In the case of federated single sign on in the enterprise, this means that Salesforce.com (the service provider) trusts Active Directory (the identity provider) and allows you access.

In the real world, the best example is your driver's license.  When you present your driver's license to the bank to prove that you are you, the bank (service provider) is trusting that the DMV (identity provider) has properly vetted you with birth certificates, social security cards, or other identity information.  Because of this trust, or federation, you don't have to carry all of these documents with you everywhere and prove to every single person that you are you.  They trust the DMV (or whatever institution in your country provides driver's licenses) to have taken the appropriate steps to prove your identity.

Don't get me wrong, IT systems are the real world.  And you just need a mechanism to trust your identity provider.  And something akin to a driver's license.  Thankfully, we have several standards that act as a driver's license: SAML, OAuth, OpenID, WS-Trust and WS-Federation. 

When a user authenticates into the service provider (in this case Salesforce.com), Salesforce.com asks for ID.  Since the application is federated with empowerID, the user doesn't have to pull out all of her identity documentation, she just needs the driver's license, in this case a SAML token.  Reaching into her wallet (actually the secure token server in empowerID), she pulls out her SAML token (actually, empowerID sends it to the service provider) and presents it as evidence that she is who she says she is and should have access to the application.

Since Salesforce.com trusts the identity provider and hence the SAML token, the user is authenticated and allowed in to the application.  No username and password (analagous to the mess of identity documents like birth certificates, etc) or difficulties in signing in.

There are other Federated Single Sign On Scenarios (this is scenario number 1, corporate login to cloud application).  But in each one, consider the SAML token (or other protocol) to be the driver's license.  Your user presents this token as identity proof to the bank teller or airline ticket representative or retail clerk and that person (service provider) trusts that you are who you say you are and lets you in.

Once you have this capability, it is easy to trust partners, customers, contractors, and other entities inside or outside of your organization and offer them single signon.  Imagine you are a book publisher who wants to sell books and offer other service options to consumers, authors and editors in an external portal. 

You won't get very far if you are forcing them to re-enter passwords and user names for each application.  Once you authenticate them once against empowerID (your identity provider), they are federated into every single one of those applications.  And the best part is that unlike the real world, they only have to reach into the secure token service once for that SAML token, it moves along with them presenting itself every time they hit a federated application.

Take a look at our whitepaper and see if any of these scenarios apply to you and let's make federated single sign on a real world solution for you.  Click the button below to download your copy of the whitepaper.

To paraphrase Gartner, Identity and Access Management is the act of getting the right people the right access to the right resources at the right time.  Central to that concept is the right people.

Think of the people that you have: employees, contractors, customers, and prospects.  Each of those users needs access to certain resources on your network and you certainly don't want to treat them all the same.  You need role based provisioning to ensure that each user gets provisioned to the appropriate applications.

As an example, your employees will need user accounts in Exchange, SharePoint, CRM, ERP, Google Apps, etc.  Contractors will need a subset of that with more limited roles.  Customers will need accounts in the supply chain software, ticket management, and maybe SharePoint.  Prospect you just want to make sure that they are in CRM and have access to general sites within SharePoint.

So how do you automate this?

For each type of user you will need an authoritative source, the Identity Store of Truth.  For employees and contractors, it most likely will be your HRIS.  For customers, it can be the billing system or CRM.  For prospects, you might want to have a self-registration page.  Each of these Identity Stores of Truth will connect to the empowerID metadirectory, creating a person object that defines roles based on what data store they come from and attributes that we know about them (department, total annual billing, location, etc).  These roles are handled dynamically and change as a user's status changes.

Based on these roles, empowerID will provision user accounts into each of the connected systems listed above.  The metadirectory will then have a joined record of each user's accounts and can synchronize any changes from authoritative sources over to the connected system.

This pertains to the ongoing lifecycle of each of these users.  As you know, users are not static, they change jobs, they move from contractor to employee, prospect to customer and their needs change.  So, provisioning has to keep going to keep up with these users' lifecycles.  This is a key part of the concept of the right person having the right access at the right time.

EmpowerID's metadirectory is constantly inventorying each of these connected systems, if it sees a change to a contractor in the HRIS, it flows that to each application, possibly provisioning or deprovisioning accounts, and most likely changing their roles in all of these systems.

And it is all handled by a visual IAM workflow.  You have probably designed this process on a whiteboard or in Visio.  EmpowerID's workflow emulates this look and feel, allowing you to map the process to your IAM process.  And, the beauty of it?  It is true automated provisioning.  Not just once but every time a change happens.

Once you have your user provisioning automated, empowerID opens up the world of RBAC and federation and password management and governance and auditing.  But start with the "right people" through automated user provisioning and you've won the first and most important battle. 

Schedule a demo now and see how it works!