All-In-One Identity Management and Cloud Security

I often talk about how a person is a person until hired, then they become an employee.  Once IT gets ahold of them, they become a user.  And this link between being a person and a user gets lost.  At its core, this is the goal of identity management, to understand that user as a person/employee.

Think about that person for a second, how many user accounts does each person have?  In each system, there is one.  And in many cases, each person could have multiple Active Directory accounts.  How do you correlate them?  How do you lump all of these user accounts into a person?  A metadirectory.

With a metadirectory, or the person directory as we call it, you can correlate all of the identities and all of the identity information into one person.  The key is to have a key, or keys if necessary.  The metadirectory inventories all of these systems with all of these user accounts and logs changes, creating an up-to-date person.

And, of course, this is where it gets fun.  Once you have this person with all of his identity information in the metadirectory, you can now authenticate against this directory, creating a federated single sign on to any of your connected applications, even in the cloud!  The roles that you create can apply to each application, creating a true RBAC environment.  Provisioning and de-provisioning are built into each application automatically; people are productive immediately.

Now, do you want to have to code each and every attribute synchronization?  No.  You need a WYSIWYG synchronization engine that defines workflows of what goes where.  Which system is authoritative?  The best and simplest example is HR and AD...HR is authoritative for everything but email address...so you send identity information to Active Directory from your HRIS, provision an Exchange account, and shoot that email address back to HR.

Make your users people again, give them the correct access, unify and correlate their identity to make them whole again.

The whole goal of authentication is security.  There is a lot of buzz around password strength and security, highlighted famously by XKCD.  Their theory is that long passwords equals password strength.  And it's true, a long password will take a lot longer to crack and if done right is remarkably easy to remember (like your favorite lyric from an obscure polka song).

The question is, will users ever take this advice and stop using passw0rd as their password?  No.  And, even if they do, they will continue to write it on a post-it note affixed to the bottom of their keyboard.  This is the inevitable and painful flaw in any password policy.

You know what solves this?  Two factor authentication.  Single factor authentication should never be allowed, you need a second factor like the user's phone and/or a hardware token.  Something that the user cannot just write down.  And that isn't guessable.  With a second factor, if someone gets your password, they still cannot access your application or data.

But, come on, are you going to make your users respond to an SMS message or spend the money on an RSA SecurID to check their email or punch in to the timeclock application?  Do you want your lowest privileged accounts having to ramp up security that highly?

Enter adaptive authentication.  The idea is that the more secure the data and/or application, the higher level of authentication is required.  So, your user logs in to the network using just his basic credentials.  When accessing email, this is fine.  Punching in to the timeclock, this is the appropriate level of authentication.

But, once your user wants to access CRM or Oracle Financials or the SharePoint site with the 10K draft in it, you want adaptive authentication.  Your authentication workflow should split out at this higher security application and ask for a second factor authentication. 

With this, you are taking a strong password and strengthening it to the nth degree.  Your user will need to provide a token or a code from their phone or a fingerprint or their first born, whatever you choose as the second factor.  You can even ramp it up and ask for something like Equifax's identity proofing service.

We will never get users to use the appropriately strong passwords we need for security, but using adaptive authentication we can add to password strength with second factor authentication on the most important applications.  What the heck, even add a third factor if it's important enough.

Google apps supports SAML 2.0.  That is basically all you need to know to achieve single sign on.  In our Whitepaper, Top 5 Federated Single Sign on Scenarios, federating with Google apps falls under three scenarios:

• Scenario 1: Corporate login to Cloud Application
• Scenario 2: Cloud login to Internal Application
• Scenario 5: Identity as a Service (IdaaS) Hub

But all of these scenarios follow the same basic principle -- the user goes to the service provider (Google Apps) which sends a SAML request to the identity provider (in this case EmpowerID) which sends an encoded SAML response which the service provider accepts and then, boom, the user is logged in.

This is federation which means the user doesn't even necessarily need to know their service provider username and password.  Here's a nice diagram from Google's developer page on how this works:

Google apps is growing by leaps and bounds in the enterprise and there is no reason to not have federated single sign-on for your users.  Choosing your identity provider wisely gives your users an easy way to access their services without re-authenticating.

Of course, you are going to have other issues with Google Apps such as the fact that their Google Active Directory Sync (GADS) only synchronizes 5 attributes natively and doesn't address how to synch your AD groups over to Google Apps.  EmpowerID can help you solve that as well, but in the meantime, get your users logged in and federated!

What is identity management?  That is a loaded question.  Ask a dozen identity management professionals and you will get a dozen different answers. 

I define it as such:

Identity is who you are, what you can do and what you can see.  Identity management is what the organization knows about you, what applications and resources you can use, and how you access them.

I put this question to all of our customer facing staff, figuring that they are talking about this topic all day long from dozens of different perspectives.  Two things immediately became clear, all of their definitions revolved around our solution AND that they all mentioned the word person (or people).

I am new at The Dot Net Factory, so EmpowerID's greatness hasn't yet biased my definition but it does give a real warning as you, the IT and identity professional, veer down the path of managing identities.  Don't let the vendor define identity management for you.  Think about what your needs are, what your business problems are, and get a solution that is right for you.

Which brings us to the second point: people.  I always joke that a person is a person until they are hired, then they become an employee; once IT gets ahold of them they become a user; and then IT never deprovisions them and they are a user for life.  Kind of dehumanizing.

But you cannot manage a user's identity.  Because each person is multiple users.  They are a user of Salesforce.com, a user of Exchange, a user of quickbooks, et cetera.  A user has a department, a title, and a role; but each application they use, gives them a different role, has different identity information about them.  Somehow you have to take all of those users and recompile them into a person. 

I can't even say employee because you also care about the identities of your partners, customers, alumni, etc.  Do not forget the person in identity management.

This is why you get a dozen disparate answers from a dozen different professionals.  Because they have a dozen different definitions of a person and a dozen ways to compile that person.

Back to vendor bias, EmpowerID does it with a metadirectory and an RBAC and ABAC hybrid model.  Our metadirectory creates a person object that is a compilation of all user accounts (even multiple AD accounts), allowing you to understand a person's identity and apply dynamic roles for access and authorization.  Schedule a demo (once you have your own IdM definition! ).

Or take a look at our whitepaper on the RBAC / ABAC hybrid approach to enterprise authorization (what you can do based on who you are!).

I had a customer years ago who couldn't keep Active Directory identity information accurate, so they gave everyone access to ADUC.  You know, so that the users could update their own address, etc.  This company went bankrupt; that's what happened when you give fully privileged ADUC access to more than the handful that should have it, you go bankrupt.

Don't go bankrupt, it's bad for the economy.

To solve this age-old problem, you need a way to manage users and computers in Active Directory with appropriate permission sets. 

• Let domain admins have their way with AD, but actually get yourself a useful audit trail
• Let helpdesk users manage group memberships and identity information without the ability to accidentally delete an OU (yes, I've seen that)
• Let end users manage their own identity information with some sense of workflow

Having an Active Directory self service solution enables you to do all of this.  But you need something a little more robust than a web page with built-in permissions to change attributes and group membership. 

This ADUC replacement should be integrated with your overall role based access control (RBAC) policy.  You shouldn't have to delegate new permissions, you know who should be able to do what.  The same system that manages access to systems and resources can provide the rules on who can change what in AD.

And with rights-based approval routing (RBAR), you can simply state the protected actions, give a role level or attribute level of who can approve and turn it loose.  Something like deleting an OU?  Can only happen with three domain admins agreeing.  Something like changing my mobile phone number?  Easy, you can do it, no questions asked.  Change a title?  Only if a director or above in HR says it's OK.

And get yourself a safety net outside of your AD backup.  Have a meta-directory that catalogs every single change EVER and it's pretty easy to restore changes or deletions without losing the old permissions.

Take a look at how EmpowerID can easily replace ADUC and add a ton more value.  And it can help you from going bankrupt (claim not verified by anyone but it's a great way to tie the blog post together).

Active Directory does seem to be at the heart of everything.  Thanks to the persistence of Windows computers, authenticating against AD is the simplest and easiest way to get in to the network.  It's a pretty strong ecosystem to start your identity.

The trouble is that your users' identities stretch far and wide nowadays.  There are tons of internal systems that they need access to, scads of databases holding pertinent pieces of their identities, even multiple AD accounts belonging to the same person.  You have data governance being handled by AD security groups without an easy way of knowing who has what access.  You have cloud applications that need to know who your user is and what they can do.

Active Directory is the most essential identity repository while somehow being peripheral.  It's weird.  I have spent most of my career in identity management (dating back to Isocor/Critical Path) thinking that metadirectories are too complicated to be truly useful.  But EmpowerID's metadirectory has changed my mind. 

EmpowerID is so simple to manage thanks to the workflow designer that it might even be easier to manage than Active Directory itself.  And it provides all of the IAM functionality that you need, right in one central place.  Built on the principles of easy to manage workflow and integrated RBAC, you populate all of your users' identity information in once place.  Authentication to internal and cloud apps happens right there.  Group management and data governance are combined and centralized even if you have multiple ADs.  And user provisioning into any system becomes easy.

Active Directory is an essential piece to Identity Management but it is very incomplete without a strong IAM suite.  You know, like EmpowerID.  Click the link below and we can demonstrate how IAM can build off of AD but not be restricted by it.

Identity management runs on workflow, but not the traditional workflow of "who approves what".   Identity management workflow is really business process automation for identities. You, as IT, know what systems and resource access should happen if a new employee is hired, or fired, or moves departments.  The workflow is the process that makes that happen.

And you should not have to code anything.  Let me repeat, you should not have to code anything.

Let's walk through an example.  Bob is hired into sales as a Senior Account Manager.  The workflow sees a new employee in your HRIS, determines location, department, title and any other pertinent information.  Roles are assigned and the workflow automatically kicks off a process for provisioning into Active Directory, Exchange and Lync.  Everyone gets those.

Seeing that the user's department is sales, the workflow provisions a Salesforce.com account and since the user's location is Des Moines, the user is given an account for the badge system and access to the networked printer.

This is where it gets cool using rights based approval routing.  The user's title is Senior Account Manager...the senior means something around here.  Because of that title, the user is given extra privileges to send out mass emails using a 3rd party tool.  But because of the cost of said mass emails, you actually want to get the CFO's approval so a subworkflow is kicked off to have the CFO approve this right.

The identity management workflows can do even cooler things in the world of authentication.  Because the user is in sales and has access to account information, the SSO workflow forces two factor authentication the first time the user logs in from a new computer and forces password reset re-enrollment quarterly.

These, and many other, workflows can be created using a drag and drop workflow designer in EmpowerID.  Of course, you could try to create them yourselves using some other IAM softwares and an army of developers, but why?  With 370+ out of the box workflows and the ability to create and customize many more based on your requirements, make identity management workflow do your work with EmpowerID.

Schedule a demo and never have to approve another IdM workflow again.

The cloud is like the wild west right now.  Cloud applications are roaming the plains like gunslingers in a Spaghetti Western.  That's a crazy analogy but the point is that all the hard work IT has done over the last decade to corral identities within your network has been rendered useless in the cloud.

Everything you know about your user is rendered useless when they go out and create an account in the cloud.  A perfectly useful account for them to do their job but you in IT have no control over how they use it.  Or know what they're doing.  You have no idea what the user's cloud identity is: how they access it, what their account is, or if they should have access to it.

You need to understand their cloud identity.  The best way to get a user to buy in to IT knowing about their cloud life is to offer them something.  Cloud single sign-on is the best incentive to get users buy-in.  Think about it, if you want to know that weird little obscure account they are using, tell them you'll help them sign on more easily with their network account.

So, how do you integrate cloud identity into your network identity?  Workflow, beautiful role based workflow.  Let's take the biggest and most common example: salesforce.com.  In this example, you have 4 basic types of users who use salesforce: sales and service, user and manager.  Two departments, two roles in each.

If you have an IdM platform provisioning users and giving them roles (if you don't, please call us!), just assign a workflow that provisions the cloud applications like salesforce.  You know the user's role, so you can assign different permissions in salesforce to a sales manager v. a service user.

Once you've created the cloud account (in this case salesforce), you know the password, you have it linked to the user's network account.  You give the user single sign on to the cloud application.  Most cloud applications use some sort of standard authentication: SAML, WS-Trust, WS-Federation, and OAuth.  Now, between the provisioning, the SSO, and the role based access, you know what the user is doing in your audit and you have controlled the wild west.

Of course, in this scenario you have also controlled what they do on network.  And you might have dozens of cloud applications that you now control.  Identity in the cloud is NOT different than identity on the network, you just need a way to manage both together.