All-In-One Identity Management and Cloud Security

One of the key concepts in user provisioning is that not all users are created equal.  An IT admin may need a user account provisioned to JIRA while a sales manager needs a user account provisioned to Microsoft CRM.  All employees get an AD account and Exchange mailbox.  Partners only get a SharePoint profile.  Role based user provisioning solves this.

With EmpowerID's integrated RBAC engine, you have roles assigned either statically or dynamically to each user, most times more than one role.  With a simple role assignment, EmpowerID assigns user accounts to that user and performs the heavy lifting of provisioning them whether on premise or in the cloud.

This video is a very simple demonstration of this process, showing the end result and how we got there.  User account provisioning does not have to be difficult or messy or most importantly manual. 

This was, of course, a very simple example, with only a handful of accounts and a handful of roles.  EmpowerID is installed and managing identities in huge enterprise environments with hundreds of thousands of identities and scores of applications.  Conversely, we have clients with identical problems with a thousand users that EmpowerID solves.

Schedule a demonstration and we will tailor it to your specific use case to see how you can solve the role based user provisioning problem.

Simple attribute sync is not difficult.  Take a key (user's alias or email address or employee ID) and decide which identity store is authoritative and synchronize the attribute(s).  What is difficult is when you have dozens or scores of identity stores.

If you tried to synchronize all of these attributes without a central identity store like a metadirectory, you would end up with a confusing lattice of synchronization scripts that could easily conflict with each other.  I'm not saying it's impossible, it's just impractical.

Having a hub and spoke solution allows you to easily flow attributes from the authoritative source to the metadirectory and back out to the appropriate identity stores.  An example would be that HR is authoritative for a user's title, then empowerID metadirectory would inventory HR, see the change and update the user's "person" account in the metadirectory.  With that change, it will need to be flowed out to the LDAP identity store and Active Directory.

If some rogue admin changes the title in Active Directory using ADUC, empowerID would inventory that change, see that HR is authoritative and roll back the change in AD.  Having the central metadirectory is incredibly powerful for keeping attributes in all identity stores accurate.

But metadirectories are complicated, right?  I saw my first metadirectory in 1999/2000 when Critical Path bought Isocor.  If you asked me that question then, I would have said, "yes, very complicated."  Ask me today and I'll say that even I can manage connectors and attribute flow. 

Consider this:

It is as simple as configuring the arrow to indicate the authoritative source.  It can be authoritative from either identity store (arrow facing one way), last change wins (arrows facing both ways), or don't sync (big red dot).  "Big red dot" is a technical term in the world of UI, trust me.

You have these attribute flow rules for every connected system in the identity ecosystem.  From the example of the hub and spoke diagram above, you would have four attribute flow rules to fill out, with empowerID doing the heavy lifting of schema detection from its connectors.  You just decide what maps and what wins.

This is just for simple attribute flow, sometimes it does get more complicated.  You may need advanced attribute transformations, more than 1 to 1 attribute flow, 1 to many, calculated values.  You may need to extend the attribute flow for complex transformations.  EmpowerID's UI allows you to easily extend the flow with these transformation, some right out of the box (for example first name & last name from HR transforming to an alias like first initial last name {Edward Killeen becoming ekilleen}) and some with custom code.  It is all built into the empowerID platform.

Having a metadirectory in place also extends attribute sync to the cloud.  Many of our customers have 20%+ of their applications in the cloud now.  You need to be able to synchronize these attributes out to the cloud identity stores.  You rarely have access to the backend database or directory, rendering scripts and simple synchronization tools obsolete and ineffective.

EmpowerID's connector framework can map synchronization actions to its API layer, allowing synchronization from the metadirectory to the cloud applications.  With this capability, you now have all of your identity stores synchronized and accurate.  Contact us for a personalized demonstration of empowerID and we can show you how to synchronize attributes and all of the other capabilities of the most complete and flexible IAM platform on the market.

I'm on the phone all day every day with clients who are either manually provisioning users or cobbling together scripts with bandaids, duct tape and chewing gum to get their user provisioning automated.  If you don't have it fully automated yet, you are not the lone ranger.

That does not mean that you shouldn't, obviously.  User provisioning should be automated, it should incorporate all of your applications (cloud and on premise) and it should tie into your access governance as well.

Let's start with the first part: automating your user provisioning process.  This is basic identity management workflow.  In the case of EmpowerID, it is VISUAL identity management workflow, meaning that the workflow is designed and configured in an easy to manage and visualize visual business process management layout. 

When you are sitting in a conference room designing the provisioning process, you are most likely at the whiteboard drawing rectangles and arrows and directories.  That should translate directly to the identity process workflow in EmpowerID, allowing your business needs to dictate your identity policy instead of your identity software dictating your business.

The identity management system will have connectors to all of your applications and identity stores.  Usually, HR is your authoritative system of record; EmpowerID will inventory HR for hired or fired employee records and initiate the onboarding and offboarding workflows.  The user account will be created in the metadirectory and based on the rules and policies in EmpowerID, will initiate workflows to all of the other affected systems and applications that this user should access.

The metadirectory sits in the middle and keeps a centralized record of all of the user's accounts and access.  This "person record" gives a whole view of the user and allows for auditing, constant updates to attributes and resultant access (whether it be roles or group membership or application access).  This makes auditing easy, makes it possible to see changes that happened outside of the system (through native access), and allows for attestation and separation of duties policies.

Those internal users aren't all of your users though.  You have partners, customers, dealers, contractors and a host of other external users.  The old "keep them in AD" practice won't work, there is too much risk there.  EmpowerID's metadirectory and workflows give you the ability to keep user accounts in the same system, design similar workflows and manage rights and access in a much more secure manner.  You can even have anonymous workflows to allow external users to create an account with limited access and send requests to internal users to grant additional access.

And, to just what applications are you provisioning users nowadays?  Certainly more than you were five years ago.  You have cloud applications, AS400 applications, web applications, and the usual suspects of AD and Exchange.  You need a modern IAM provisioning software (like EmpowerID) that can handle provisioning to all of these applications.  EmpowerID has direct connectors to most major applications and the ability to map APIs to workflow shapes for ones that we don't.  Most importantly, by having a framework to quickly deploy and manage connectors, EmpowerID can connect to almost anything, keeping user accounts current and secure.

The third part that is important is to integrate with all other aspects of Identity and Access Management (IAM).  Most legacy applications (I'm looking at IBM and CA and Microsoft and Quest here) are the result of myriad acquisitions and mergers and the products are put together in a way that not all modules work together.  EmpowerID is built from the ground up on a single code base and the platform shares common components like the metadirectory and RBAC engine and workflow studio. 

So, if you are provisioning to the cloud, you can create role based provisioning so only salespeople get a CRM account and they are automatically federated for single sign on and application roles.  When you reset your password in AD, it flows and resets passwords in all applcations.  If your user is promoted, this reflects throughout their identity, changing application access and roles within the application.  If a user attempts to access a highly secure folder, a second factor authentication can be launched to ensure they are who they say they are (and have what they are supposed to have). 

It needs to be a full identity ecosystem.

So, automate your user provisioning process but do it with an identity ecosystem that covers all of your identity needs.  Even if you don't deploy all of it right away, have a platform that can handle all of your identity needs.

Users and their access are inextricably linked.  The National Institute of Standards & Technology (NIST) estimates that users are only 58% productive without their proper access.  So, why are provisioning processes often separate from access governance processes?

It should be an identity ecosystem.  When a user is initially provisioned from HR (or a contractor database or a customer self-registration), you apply an initial role to that user dynamically based on what you know about them.  That role (or roles) determine in which systems the user needs to be provisioned.  An example is: sales rep in Toledo will need an Active Directory account, an Exchange mailbox, an ERP account and a salesforce.com account.

Once that user has these accounts, the user will need to have roles within these applications.  The ability to modify groups, access SharePoint sites, place customer orders, modify CRM records and anything else that is role based.  This is the idea that you are provisioning access and accounts.

Some systems, like your VPN or shared folders or Business Intelligence app, may use AD groups to grant these roles.  And this is why provisioning access goes beyond just the application role based access control listed above to group based access control.  No organization can manually keep up with all of the group membership requirements that is required; you need to provision group membership dynamically based on rules and roles. 

Groups are intertwined in your everyday corporate life, from distribution lists to printer access.  However, role based access control is arguably the more modern approach to access governance, reaching outside of the Microsoft ecosystem better and being generally more flexible.  Having group membership controlled by your role makes this easy.

This can all happen dynamically in the first minutes of a user's employment, but users don't sit still for much longer than that.  Estimate vary, but on average, there is a 20% internal turnover per year.  These are employees that are still with the company, but have some sort of job change whether it be a redeployment, promotion, move, or restructuring.  Then the whole identity and access provisioning scenario starts again.

Having a metadirectory sitting in the middle of this identity ecosystem gives you flexibility to inventory HR or AD or any other authoritative source or sources to detect these changes.  Once the change to a user happens, all of the application provisioning can be re-evaluated, de-provisioning accounts they no longer need, provisioning new accounts and changing roles within the applications.

Group memberships get re-evaluated, removing access to old and granting access to new.  EmpowerID can generate reports to show new resultant access for the new roles for auditors or new managers to review.

Then if an offboarding event does happen, all accounts and access are linked to an EmpowerID person object and can be removed in one fell swoop, with accounts de-activated and an audit trail to show access has been removed from everything except their 401K account.

Too often, provisioning is looked at as a way to create an account without considering that access is as important as the user accounts.  Then the lifecycle of the user needs to be considered, again not just as an account but the role and access level required.

EmpowerID's unique visual workflow component, metadirectory and RBAC engine work together as part of the IAM platform to keep privisioning, evaluating and re-provisioning user accounts and access throughout a user's lifecycle.

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.

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.

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!

Cloud provisioning and single sign on go hand in hand.  IT wants only the right users to have the right access to cloud applications.  Users want that access and to not be bothered having to re-authenticate (well, actually, they say things like "why should I have to enter another password" in a nasally voice usually).

The problem is that the Identity Management industry evolved from the on-premise world and is stuck in its own tracks.  Most vendors' provisioning solutions were either developed separately from their single sign-on solutions or just don't exist in one platform.  Most of the federated single sign-on vendors don't even have a provisioning solution.

So how do you get that perfect world of a user being provisioned into a cloud application based on their role (or something you know about them), getting the correct application role, and federating to keep the number of passwords down for your users?  And, to top that off, keep your security team happy by de-provisioning that user when their job changes?

You don't do it with cloud vendors or traditional IAM solutions.  EmpowerID's tagline is a "New breed of Identity Management" and this is why.  The platform was built from the ground up without the burdens of acquisitions or partnerships to create the full suite.  So, the whole product line shares the same RBAC model, the same API layer, the same metadirectory, the same visual workflow designer.  It is a true platform.

What that does for you is allow you to have the same workflow for role based provisioning for both the cloud and on premise applications.  Map your business roles to application roles and then apply those roles to role based authentication.  It means that if you provision a user in salesforce.com, you can federate using empowerID as the identity provider, giving the elusive single sign-on for that user.

And, you can get even more granular than that.  If the user is accessing highly secure resources, you can force two factor authentication only when the user tries to access that resource.  Picture this, your finance director logs in to Windows in the morning and checks her email and browses the internet to see what the markets are doing.  She clicks on the link to look at the accounts receivable report, empowerID sees that is considered highly secure, and sends a text code as a second factor authentication; she simply enters that code and is authenticated for all resources of that access level.  When she goes into salesforce.com to see the forecast, empowerID knows who she is and authenticates her automatically.

You have just increased security and ease for your user.

Now for the fun part.  Your finance director is looking at a commission report and realizes that she should be in sales.  She changes departments which is reflected in Peoplesoft.  EmpowerID inventories the HR system, changes her department and roles, which deprovisions her from access to the finance system and provisions her a new account in the cloud based marketing automation system.  She now has an account in the cloud application and single sign on to that app.

We have all been wanting the complete soup to nuts identity and access management system that handles all of this seamlessly.  The world got more complicated with cloud applications but having the new breed of identity management software allows you to provision to cloud applications, offer single sign on, and achieve your IAM goals.

Take 30 minutes for a personalized demonstration of empowerID and see how we can help you achieve all or some of these lofty goals.

Your finance department is watching the cloud.  Not because they are tech literate and following IT trends, but because they can cut your budget quickly with cloud applications.  And it's up to you to help them before they help themselves.

In the on premise world, if a user leaves the company and you keep an application account for a few extra weeks, it only hurts your security.  In the cloud world, you just paid an extra month of service for a user account you didn't need to.  Take a look at your internal and external turnover, pull out a calculator and see if you can make a dent in your budget by managing your cloudy accounts better.

The way I see it, you have two simple options to help you reduce your monthly cloud expenditures:

• timely provisioning & deprovisioning of all user accounts
• role based provisioning to the cloud applications

The first is obvious, if a user leaves the company, you need to deprovision ALL of their accounts, on premise and cloud.  A metadirectory that has inventoried all of their accounts from connected systems (AD, HR, ERP, Salesforce, Gotomeeting, etc) can delete or deactivate those accounts quickly and easily.  This is your external turnover.

But what about internal turnover?  That user who moves from marketing to sales and needs new access to some systems (SharePoint sales site and the line of business quote application for example) and different access to other systems (like Salesforce)?  And they certainly don't need access to applications like their cloud based marketing automation software (Hubsport or Eloqua).

They are going to have a different role in your metadirectory (now sales in Iowa instead of marketing in Ohio) and that can trigger the workflows that will provision new user accounts (in that quote application), change access in some (a different native application role in Salesforce), and deprovision access in their marketing automation application (like HubSpot or Eloqua).

Did you see what just happened by managing application access and provisioning by roles?  We just deleted a cloud based application account (the marketing automation account) and saved the company money.  Every single month.  If you are handling this manually or allowing the line of business (marketing department) to manage it, chances are the company is paying for a lot of cobwebbed accounts in your cloud applications.

Keep finance off your back; take a look at empowerID to manage your role based provisioning for the cloud.