All-In-One Identity Management and Cloud Security

You know that guy in accounting you just don't like and wish you didn't have to talk to?  Well, there's a chance that you don't have to!  Separation of Duties (SOD) to the rescue.

It doesn't really work like that but there are some mutually exclusive roles.  One where if you have these sets of permissions, you cannot have another set of permissions.  Some of these are security related (for example, you have permission to create a user, you should not have permission to add them to the financials group, this keeps one person from being able to create a fake user to access critical financial reports).  Some are regulatory (for example, in a bank the analysts should not be able to have access to customer records, the bankers should not have access to analyst reports).

Once you are controlling permissions and access with roles (using Role based access control aka RBAC), it is simple to make roles mutually exclusive.  If you are a member of one role, you cannot be a member of another.  If you are a member of one role, you need CEO approval to be a member of another.  This creates a separation of duties.

I always picture it in action like a Hollywood movie...you need two keys to detonate the bomb and there is a tense standoff as the one guy knows they shouldn't do it.  Separation of duties is just like that.  Just. Like. That.

Once you've configured your roles to show what your users can do, you need to take that next deeper dive into what that same user shouldn't be able to do.  A good mapping of roles and SOD rules will make your organization more secure and your auditors much happier. 

If you are one of those "a picture is worth a thousand words" types, give us 15 minutes to show you how SOD works in RBAC by scheduling a demonstration.

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.

SharePoint is becoming more and more prominent both internally and externally.  Since access is often a hybrid of internal and external users, SharePoint identity management is especially important to do right.

You have to make it easy for these users to access the correct SharePoint sites based on their role(s).  An internal user needs certain access and an external user needs different access; it's like two sides to the same coin.  For example, both need to access billing records but have different permissions on what they see.

Where things differ is the user experience.  You manage internal users based on having Active Directory accounts and then grant access based on SharePoint, AD, or other groups and roles.  External users have a whole different set of identity issues.  You don't necessarily want them in Active Directory so you don't manage them with AD groups or even SharePoint groups...so how do you manage them?

Having an external directory that can manage SharePoint permissions and assign roles is essential.  Our own product, EmpowerID, does that very well.  Once you have the directory for this, there are three main user experience components you need to address:

1. Registration
2. Login and SSO
3. Password Reset

Since they aren't internal users you may not have an authoritative source for these users.  If you do, provision them from there.  If you don't, you need a registration page that collects the relevant information and sends their details to the appropriate system or person for authorization.  For example, anyone can have general access, but if they indicate they are a customer, have the registration page confirm with CRM or their account rep.  Keeping these external users in a separate directory allows you to manage their access with the proper granular controls.

A user needs to be able to login easily.  Accepting federated logins from Facebook or Google enhances the ease of your portal for customers.  Having a system to accept federated SAML tokens is needed for this.  SharePoint 2010 allows directories like EmpowerID, for example, to act as a SharePoint claims provider.  This way, users don't have to remember another username and password.

But if you don't federate, you will need a good way to allow a user to reset their password without calling you.  Since you are often displaying important confidential information to your external users, having a method for two factor authentication or identity proofing will keep this data secure.

Remember, the fewer barriers to having your external users interact with you, the more likely they will continue to spend money with you.  Understand their identity, provide them the same or better service than you do your internal users and you will keep a customer for life.

Schedule a demo to see how some of our customers have solved this identity management issue with SharePoint and see how to improve it for your customers.

I am a big fan of role based access control (RBAC).  My entire product line is built on the concept.  Roles control what systems a user gets provisioned in, what level of access they have in those systems, what files and folders they can use, and basically how they do their job.  Having multi-hierarchical roles means that you don't even have to define every single role, they define themselves.

But even with the greatest role structure ever created, there is going to be that one folder or that one system or that one cloud application that is just a bit different.  You don't want to have to create a new role for this one single use case, you might just want to modify it a bit.

Enter Attribute based access control (ABAC)!  Attribute based access control is the concept of having your permissions defined by an attribute in Active Directory or other system to determine if the user has access. Combining its power with RBAC gives you the best of both worlds.

Say you have an HR Manager in the Southwest region and your RBAC rules gives him/her and all of his/her peers access to applicant resumes either in a folder or your HR system.  But, your company is in the process of hiring a new CFO.  Somebody has to review those resumes but it is highly sensitive and only one manager is tasked with it; the rest should not be able to see them.  You don't want to create a new role just for this one task but you know that certain managers are identified in AD as "top secret clearance".

When creating this new access, just use the HR Manager Southwest role, then add the attribute of "top secret clearance", and anyone in that role with that clearance is given permission to manage these resumes.  As users' roles and clearances change, that access will always be dynamically assigned to the correct users.

I have often heard, "how is this different from dynamic groups?"  Dynamic AD groups mostly are used for file systems; we offer these as well, but to have dynamic role or hybrid role based and attribute based access allows you to extend these permissions past the file system and out to provisioning, application access, even to the cloud applications.

If I didn't describe it well enough or if that cool picture didn't really cover it, let us show you how it works with a personalized demo.  With an RBAC / ABAC hybrid structure, your users will have the exact access they need when they need it.  Also, download the whitepaper!

Managing your internal identities is the bread and butter of identity management.  You know who your users are (at least you should) and you have a good idea of what they need to do their jobs.  If you don't, call us and we'll get EmpowerID running toute suite.

But there is a whole new realm of identity management you need to think about: partners and customers.  Your external identities.  You don't hire them so you probably don't have a tried and true process of provisioning.  You certainly don't want to give them Active Directory accounts but they need access to a lot of services and systems that you provide.

We are seeing more and more of this in the marketplace, how to expose services to your external identities and how to track them.  It sounds just like identity management but not all of the traditional solutions work here.

This is where the platform approach really works.  You can provision new users, heck even offer self-provisioning, and assign roles immediately.  These roles have access to certain parts of the application or portal.  The IAM platform can confirm that this is indeed a customer in the CRM system, and provide advanced access or more privileged roles based on any number of criteria that you know about them.

By storing this external user identity in the metadirectory, you can authenticate directly against that directory, utilizing SharePoint 2010's claim provider functionality.  Now, in one place you have provisioning, role assignment, and authentication.  You can easily keep track of your external users, have an audit trail of their authentication and role changes, and manage external customers and partners like they're employees.  But easier.

Gone are the days of trying to create a separate domain for external users and not being able to restrict access to customer facing applications.  Utilizing the EmpowerID platform, you can treat customers, partners and other external users with the same role based security that you do your internal users.

Take a look at what we did for a very large insurance and healthcare portal to help manage access for external users and schedule a demo now!

We get involved in some very cool intricate discussions on identity management; delving into federation, RBAC, provisioning workflows, all the really fun stuff.  But sometimes you have to step back and realize that there is some blocking and tackling needed.  You need Active Directory self service.

End users are an incredible source for identity information and permissions management.  What you can't automate, delegate.  And this is very true.

The problem is that Active Directory houses some very sensitive information and many extremely important business processes are keyed off of it.  As such, you can't let an end user change their title or direct reports or gain access to the shared folder that houses the 10Q documents.  So, when delegating, keep RBAR in mind.

What's RBAR you say?  Rights based approval routing.  The idea that you take your roles and assign what can and cannot be changed in AD based on who is asking.  If it's the title attribute and the requester is the VP of HR, you let the change happen.  If it's the mobile phone number and it's the user requesting it, make the change.  If it's the telephone number and the user's manager asking, route that approval over to IT for an official OK.

It's really that easy.  It takes IT out of the process unless it's something that they need to know and/or approve.  It gives control to the business owner who should know what needs to happen.  And it maintains the integrity of Active Directory.

This RBAR concept also applies to Active Directory group management.  Different groups have different levels of security.  Anybody should be able to join the "book of the month club" group; but an approval should be needed to join the "Top Secret book binding project" group.  CEO approval should be needed to join the "10Q analyst call" group and HR approval should be needed to leave the "Employees on probation" group.  RBAR it.

What happens when you flip the tables and offer file share access via self service?  Nothing different, apply the RBAR concept to requesting access to a resource.  Don't just rely on the outdated AGDLP method to manage access, utilize roles and RBAR.

I could go on and on but our whitepaper already did that, discussing how to delegate permissions into AD without giving permission to AD.  Take a look.

When you start work in the morning, you authenticate against Active Directory; when you start thinking about identity and access management, you start thinking about Active Directory.  Active Directory is at the heart of it all but is often oddly neglected.

Identity and access management is a lot of things: user provisioning, user deprovisioning, single sign-on, role based access to systems and resources and my favorite the whitepages.  Seriously, the whitepages.  The whole point is to enable employees to do their jobs and one of the lacking things in many organizations is the ability to find co-workers.

Active Directory provides the mechanism for this but often times is neglected.  Take the "Mike Smith example".  In an organization of over 10 people it is statistically probable that there is at least one Mike Smith; in any organization over 100 people it is a statistical certainty that there are at least three Mike Smiths.  This is advanced math, please trust me.

There are a few ways to tell these Mike Smith Dopplegangers apart...department, title, location, middle initial, picture, et cetera.  And the global address list exposes these.  But what if these attributes are not in Active Directory, as they very often are not.  You have to synchronize Active Directory with your HRIS or other authoritative source.  And do it often because department, title and location change.

Easier said than done, you say?  Well, no, it is as easy to do as say.  Synchronizing Active Directory is one of the most elemental and easy accomplishments in identity management.  Most, if not all, IAM platforms eat this stuff for breakfast.  EmpowerID is configured to do it in the first day of implementation, if not the first morning.

As mentioned above, IAM encompasses a lot of great functionality, but let's start with Active Directory.  Make it accurate and the rest of your day just got easier.  Give us 30 minutes to demonstrate this building block of IdM and we think you'll go out and solve your own "Mike Smith" problem.

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.

While talking to a customer today, he mentioned that Google Apps didn't have a self service password reset option.  I can't say I didn't believe him, but I was a bit incredulous.  Gmail has a password reset, why not Google Apps?

I quickly googled the situation and found this in the Gmail section:

If your password isn't working, you'll need to go through our password recovery process. Google Apps users, please contact your organization's IT admin for help with password recovery.

Wow.  A service designed to reduce your organizational overhead requires helpdesk intervention to reset a password.

Once confirmed as a problem, what about a solution?  There are two ways to go about this, Google Apps password reset or Google Apps single sign-on.  It depends on your infrastructure I'm sure and I'm probably looking at this from a very EmpowerID-centric view, but neither is a difficult proposition.

Once you have your central identity repository (metadirectory) connecting to Google Apps, it's easy enough to utilize your current self service password reset solution to change your password and synchronize that with Google.  This only works if your self service password reset solution can call the Google Apps APIs and shoot along the new password.  This isn't always the case.

But if you go the extra couple of inches and federate, you take this password completely out of the equation.  Google Apps federated single sign on means that your users don't need to remember another password, their main network logon is all they need to know.  If they forget that password, the self service password reset solution you have in place already works; they change the password, sign in and BOOM, they are federated with Google Apps.

You no longer have to worry about Google's inexplicably missing password reset feature because your users are authenticated automatically and you have password reset in place.  As great as Google Apps password reset would be, Google Apps SSO is even better.

Take a look at this whitepaper on the Top 5 Federated Single Sign On Scenarios to see how you are going to architect Google Apps SSO into your environment.