All-In-One Identity Management and Cloud Security

Delegate and Automate.  The first two words of IT.  It is especially true with respect to managing Active Directory.  There are a lot of authoritative sources of identity information that Active Directory needs and not one of them is your help desk employees.

And that's one of the main issues with managing AD, it often falls into the help desks' hands.  They get an email from HR saying to create some users.  They get requests to add users to AD security groups.  They might get an email that Jane Doe got promoted to a new job in Operations.  And for all of these changes, they have to have access to Active Directory Users & Computers (ADUC).

Once you have access to ADUC, you have access to ADUC.  By that I mean that the help desk user can not only create a new user but delete an OU.  Not only can they add a member to a security group but they can make themselves a domain admin or member of the executive security group.  It just isn't that safe or secure.

So you want to be able to delegate and automate your Active Directory management.  Have end users have only the access they need to make changes.  Give them a self service portal that follows pretty strong workflow rules, giving field level security to changes on their profile or their users.  Give them the ability to request membership in some groups and not others.  Allow them to manage the membership of a group that they own.

By using rights based approval routing, anything that user is allowed to do is done instantly.  Anything that needs approval from another user is routed for their approval.  Anything that they shouldn't even see (the distribution group of users on steps of discipline for example) never appears before them.

EmpowerID allows this self service management with a level of granularity and security and role based access control that makes ADUC completely irrelevant.  Grant access only to make changes in AD that the user is allowed to.

But that doesn't cover everything.  Automation is your other big step.  Creating a user still shouldn't be done manually.  You probably have an authoritative source like HR that can be inventoried to see if a new employee exists or if an existing employee has changed.  Once the new user is inventoried, EmpowerID will provision the user into Active Directory or make changes to their job title or any other change.

These new or changed users will have a specific dynamic role and will be provisioned into the correct systems, given access to the right resources and be a productive member of the corporation immediately.

With the right combination of delegation and automation, you don't need to have ADUC access for any user.  You can manage all of the AD objects and attributes without the "everything" access that comes with native tools like ADUC.

Take a look at our whitepaper on replacing ADUC and schedule a demonstration of how we can help you delegate and automate.

Not all applications are created equal.  Not all users are created equal.  Different users need access to different applications; different users need different access to these applications.  We call this role based provisioning.  Based on a user's role they get access to the appropriate applications.  Again, based on their role, they get differing level of permissions within those applications.

The interesting part is that you also have on premise and cloud applications to provision.  It's not enough just to create an AD & Exchange account and let the application owners handle the rest.  Not in a true identity management system, one where you are managing roles and permissions centrally and dynamically.

Centrally, you have a role repository and metadirectory.  To correctly provision all of these users to these disparate applications, you need connectors to all your applications.  Building these connectors based on APIs allows you to map any roles and attributes from your central identity store. 

It doesn't matter if this is an on-premise or cloud application, the principle is exactly the same.  Your "person" identity in the metadirectory "joins" all of your accounts.  If your role says that you should have an account in the application, the connector creates the account and then inventories any changes that affect it going forward.

If your user changes jobs, automated provisioning means that their applications and permissions within those applications change.  Moving from Finance to Sales?  Your accounting software application account is deprovisioned and your Salesforce.com account is provisioned.  Role based provisioning lifecycle!  There isn't even an acronym for that it's so cool.

This is what identity and access management is about, giving the right users the right access to the right resources at the right time.  Automated provisioning really is this powerful and possible.  Let us take you on a tour of EmpowerID to show you what it can do.

Users have a lot of accounts; it keeps both IT and users busy.  The trick is to give them the accounts that they need and only the accounts that they need.  Automated user provisioning is essential.

The "person" directory is the foundation of how automated provisioning should work.  A person account should be created for each user (full time employee, contractor, partner, customer, etc).  This person account should have enough information about it to start a chain of provisioning workflows that create a joined account for each application the user needs.  We call this role based provisioning.

Let's start with how to populate the "person" directory, or metadirectory.  The metadirectory will inventory an authoritative source (HRIS for employees, a spreadsheet for contractors {just kidding}, CRM for customers and partners) to check to see any new users and provision a person account with attributes flowing from that or any other system.

Dynamic roles are provisioned (assigned) based on those attributes.  Based on those roles, the user gets an AD account, a salesforce.com account, an SAP account, line of business app accounts, a Jive account, and whatever else their role and your imaginative workflow decides.  Role mapping determines the user's role in each of these systems.

This provisioning workflow is designed around your business rules and processes.  EmpowerID offers a visual workflow designer that has almost 400 out of the box templates and the power to customize each worfklow with 400 different actions or shapes.

The provisioning workflow is kicked off as soon as the metadirectory inventories the authoritative source and determines this is a new user.  The workflow will create the person and automate the user provisioning for the appropriate applications based on roles, creating mailboxes, updating appropriate group memberships and basically doing the work to make a user a productive employee.  This is automated user provisioning in a way that matches your business process.

Speaking of business processes, ever notice how there are some one off situations?  A user account needs to be provisioned through an alternate channel?  Opening up the applications (or ADUC) themselves is a security risk if you just have admins go in there with no means to audit access.  Using these same provisioning workflows, you can design a form, assign role based permissions and have an admin kick off the process through delegation.  It is auditable, access can be made temporary and when the metadirectory inventories the systems it will know from where this account originated.

In our years of experience with empowerID and automated user provisioning, we have seen that no two use cases are the same.  But the process almost always is.  With configuration (not customization), you can have your user provisioning process automated.

If you want to see how it's done, let's take an hour and demonstrate these use cases for you.  Schedule a demo now!

Getting a user provisioned and productive on your network is one thing, getting their cloud accounts sorted is a whole other ball of wax.  In the old days, you had Active Directory, Exchange, some line of business applications and ERP this and that.  Presto, boomo, you had a provisioned user.

Now if you want to automate the user account provisioning process, you need to account for any cloud applications the user has.  These cloud applications have different UIs, are owned by different lines of business and generally add a wrinkle to your identity and access management that you just don't need.

But it's the world we live in and we have to somehow manage cloud identities with our internal identities.  The three main things to worry about are: 1) provisioning / deprovisioning, 2) role based access control, and 3) federated single sign on.

Automating provisioning and deprovisioniong is the first and most important step.  You pay for these accounts monthly per user so if someone has left the company, you want that account gone immediately.  An IAM platform like empowerID will have connectors to all of your major cloud applications like Salesforce, Google apps or Hubspot.  For those without an out of the box connector, building one with the applications APIs is pretty easy. 

Unless your IAM solution can do role based provisioning, your user will always have this account though.  Remember that provisioning isn't a one time affair, it is a lifecycle for the user, make sure that your automated provisioning workflow (and deprovisioning) takes into account the user's role or attributes and deprovision the account if their role is no longer eligible for the application.

But provisioning these accounts is pointless if you still have to go into the application and manage the user manually.  Application level role based access control (RBAC) is built into most applications.  Most IAM platforms have enterprise level RBAC.  Role mapping is essential for cloud applications, map the enterprise roles to the application role during provisioning and as your user moves around the organization.  An example is Salesforce, if your user is promoted from sales executive to sales director, their enterprise role will change; a good IAM platform will then change their cloud application role along with it.

Last, but not least, is the federated single sign on.  Your users have increased their number of application passwords exponentially (that is a bit of an exaggeration), make sure that you are federating with your cloud applicaitons.  SAML and other standards have made this easy if your IAM platform supports it.  We have a whitepaper on the Top 5 Federated single sign on scenarios, take a look and see what matches your needs.

IT departments spent the better part of the last decade figuring out corporate identities.  Most IAM vendors built their "platforms" before the cloud became so prevalent.  EmpowerID was conceived and built from 2008 onwards with the cloud in mind the entire time.  It is a platform based on a single code base that allows you to manage the provisioning and deprovisioning of cloud accounts, their roles and access, and federation all within a single IAM platform.  You do the work once for all identities, whether it's internal or cloudy.

A demo of this complete ecosystem for your users' identities will show you how simple this can be to manage. 

Talking to a client the other day about enterprise to cloud access, it became apparent that before considering cloud SSO, cloud provisioning needed to be taken care of.  More than that, role based cloud provisioning.

And this is where it gets tricky in the IAM marketplace.  There are a few companies offering cloud single sign on and doing it well.  They just don't have the platform in place to integrate with the on premise world and do role based provisioning to the cloud as part of that solution. 

And, think about your business goal here for a second.  You want to make sure that the right users have the right access to the right applications.  So, first you need to do role based provisioning; anyone in sales and support needs access to salesforce.  Only those users should be provisioned; after moving to another department they should be deprovisioned.  Data security is one thing to consider but so is license consumption...you pay monthly for these licenses.

Once you've provisioned the correct users to the cloud application (in this case salesforce), you need some role mapping.  That sales rep should have different access than the sales manager than the support rep.  Map your corporate roles to the cloud app role and not only do you get user accounts for the right folks but they get the right access.  As they move jobs, the dynamic role in your enterprise directory maps to the cloud role and presto boomo, accurate access to cloud applications!

And, now for the thing that people worry about.  Cloud single sign on...federating with the cloud application.  This is arguably the least important step but the one that gets the most attention.  Who cares if you only need one password if you have the wrong users getting access?  Luckily, it's possible to do all three and leverage the same directory if you can do SAML federation from the directory that is handling the cloud provisioning and access.

There must be others doing all three aspects of this cloud provisioning, but if any of this rings true to you, schedule a demonstration of EmpowerID and see how to get the right users the right access to the right cloud resources, and SSO them while you're at it!

There are some things that only your users know.  So why not make them the authoritative source for that identity information?  Some examples would be mobile phone number, home phone number, emergency contact information, and oddball information like shoe size.

Providing Active Directory self service gives you a good place to store this data.  Most of these items have attributes in AD and you can easily synchronize that information from AD to your HRIS or emergency notification system.  You can even then start making dynamic Active  Directory groups based on the information.

But you don't want to open ADUC to just anyone so you need a role based Active Directory user interface for self service.  The reason for role based is you need to have security built in to the self service web page so that I don't go and change my colleague's title.  You'll need to have rights based security allowing a manager to change some fields for their employees and the employees to have access to change other fields.

You then want rights based approval routing to make sure that somebody is there to approve any changes that need approval, whether via email or an approvals dashboard.

We have a whole whitepaper on how to replace ADUC, take a look.

But then there's another issue.  What if Active Directory isn't the place to store the information?  For example, you have union employees who need to update their union membership with HR every once in a while.  You don't want that information flowing through AD to get to your HRIS.

We solve that with a metadirectory.  The metadirectory has pretty flexible attribute flow rules so you can create a self service page using our forms designer, have it update the metadirectory (again, using rights based approval routing) which flows directly to HR without AD being in the middle.  To use technical jargon, presto bammo, you have self service updates without IT having to be involved.

This is probably EmpowerID's most basic and simplest use case, with almost the entirety of this functionality able to be installed, configured and deployed in two hours.  Give us a shout for a demonstration and we'll have you up and running in no time, delivering Active Directory self service for user and group management.

Back in the old days, user account provisioning meant "get that guy an Active Directory account" {note: old days not that long ago}.  And the world was easy, provision an Exchange mailbox and your user could get going, productive as the proverbial bee.

Today, you have bigger fish to fry with cloud applications, multiple AD user accounts, line of business applications, and myriad other accounts that need provisioning.  This all has to be sorted out, provisioned based on roles (marketing probably doesn't need access to financial systems, engineering can probably do without SalesForce access for example) and kept constantly updated.

Having a "people directory" solves this.  Each person has an account that is linked to all of their user accounts whether it be Active Directory (Exchange, Lync, etc), CRM, ERP, weird cloud applications.  Workflow rules can provision the user from an authoritative source (usually the HR system) and give them all the accounts they need based on their role (I love role based provisioning!).  A constant inventorying process will detect any changes and change access based on that.

Your user leaves the company?  Boom!  De-provision all of the accounts at once.

Take a look:

User provisioning and deprovisioning should be that simple and that automated.  Joining user accounts, monitoring directories and databases for changes, keeping accounts active that should be active, inactive that should be inactive.  All done because you have a "people directory."

The first time I saw that graphic, I already realized the benefits of this type of automated user account provisioning.  I've seen enough complex corporate environments to know how important this is.  But it was the box at the upper right that knocked my socks off.

Users can authenticate against this directory.  That means that using SAML or WS-Trust or other standards, we can federate with any application that supports it.  Users get not only the benefits of role based provisioning and RBAC, but single sign-on as well.  And, the people directory obviously knows what apps they should have access to, heck, it provisioned those apps.

Let's summarize: lots of applications and systems, easy provisioning and deprovisioning, role based access control and federated single sign-on.  Would it shock you if I said EmpowerID makes this easy and installs and configures in a fraction of the time you would expect?  Let us show you, schedule a demo.

User account provisioning isn't really rocket science.  You want users to be able to do their job from day 1.  What you don't want to do is just provision a user account in Active Directory and call it a day.

Remember this stat: a user is only 58% productive without the proper permissions according to the National Institute of Standards & Technology.  So, when provisioning a user, give them more than their AD account; provision that user to every system that they are supposed to be in.  Don't lose 42% of a user's productivity.

Consider what you know about a user from your HRIS: name, department, title, location, shoe size; all the relevant identity information for you to decide their most basic roles (you can determine more granular roles as you learn more about them).  From these basic roles, you can provision them into the correct systems.

To take that identity information and turn it into role based provisioning, you need workflow.  Workflow isn't just approval routing, it is the ability to set a business process within your provisioning and access control.  For example, the first box in this workflow is what location your user is in...depending on location, your user is provisioned into the proper card access system and put into the correct security group for printer access. 

Once that workflow is complete, every user returns to the next decision point based on department.  A user is provisioned and is given access to Salesforce.com if in sales or service, to Quickbooks if in finance, etc.  Of course, you can be more granular but people stop reading blogs if you get into too much detail!

Now the third workflow kicks in based on a piece of identity information not usually associated with roles: shoe size.  Each user/employee is given a pair of shoes for the company's annual Race for a Good Cause.  This is where the ability to have a hybrid of RBAC and ABAC comes in handy.  You want your supply chain software to provision a different color shoe based on departmental role, but also give the correct size based on an AD attribute.  Simple, a hybrid approach to RBAC and ABAC applies to provisioning as well.

Now your user has an AD account and, thanks to role based provisioning, has been placed in the correct systems and security groups, is operating at 100% productivity on day 1, and most importantly wearing the correct color shoes.

Click below to schedule a demonstration of how to manage role based user provisioning and extend it into an ongoing RBAC process.