All-In-One Identity Management and Cloud Security

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.

A common requirement for single sign on (SSO) for partners is that access to systems be role based.  This means that when a partner authenticates in to your system, you can give granular access to this user based on their role (or what you know about them).

For this to happen, you have to actually have roles and RBAC incorporated into your identity management system.  Specifically, it has to be ingrained into provisioning.

When provisioning a user, you can apply what you know about him/her to create some dynamic roles such as location, partner organization, title, et cetera.  As that role is defined, you can bake rules into your provisioning workflow to determine what systems he/she needs access to.  For example, a VP in your reseller partner organization will get management access to Salesforce as their account is provisioned.  The purchasing agent in your distributor partner gets access to your supply chain system for the products that they are involved in.

This idea of role based provisioning is the pre-cursor to role based access control.  You want your provisioning workflows to put users in the correct systems only.  Just giving them accounts in an Active Directory OU is not enough, you need it granular and you need it to be accurate.

This is where a visual workflow designer makes a huge difference.  It is much easier to design decision trees if you are doing it the way you would design it on a whiteboard, with easily understandable shapes and logic.

Your partners vary more than your employees, they have different needs, offer different benefits to your organization and should have different access.  Role based access control and role based provisioning are more important for partners than employees even.  You want to control what they can do on your network even more tightly.

Creating granular roles and supplementing it with attributed based access control (ABAC) will enable you to keep your partners effective and secure.  Let us take you for a tour of how to design these role based provisioning workflows and put partners in their place!

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!

SharePoint has always been a good tool, but like most it's useless if it's not adopted (hello, self service password reset!).  You have to lower the barriers to entry for SharePoint use while maintaining a strict security policy.  You certainly can't make it so easy to use that your maintenance staff has access to your 10K report document repository.

The trick is SharePoint single sign-on (SSO), no?  Users authenticate into AD, get put in some groups, you go through the people picker and give site access to groups and BOOM, you're done.  No.  You're not done.  That works for about one day until users change jobs, you create a site for partners to access, you have a site for ex-employees to transfer their 401K, and so on and so on.

You need to fully integrate SharePoint single sign-on into your role based access control for employees, partners, contractors, alumni, customers, etc.  Use varying levels of authentication for each, you are able to offer SSO but utilize roles for what sites each has access to.  If the roles are dynamic (and they should be), you never have to touch them again.

But what does this have to do with single sign-on, that sounds like authorization not authentication.  Here's the key...each of those types of users (employees, customers, partners, etc) are going to be able to authenticate a different way and have access to the correct sites.  We call it adaptive authentication.

For example, a customer can authenticate into SharePoint using their Facebook credentials.  By having a SharePoint claims provider (such as EmpowerID), that customer is authenticated and has access to all public information.  If the customer wants to view their account information, they will need a higher level of authentication and they will be prompted to verify who they are with their customer credentials or EmpowerID account or even a second factor authentication like an SMS message.

The same thing happens with your employees.  The user logs in with their EmpowerID credentials and has access based on their role.  But we also bump up the authentication level and require an RSA token or biometric authentication when they try to access the company financials.

All of your users can access what they are supposed to with one set of credentials and they don't even need to have an Active Directory account to make it work.  BUT you are also able to selectively heighten authentication policy based on the role and site being accessed.  It's not a matter of just being a member of a certain group, it goes much beyond that all the while reducing barriers to entry for your users and keeping your security policy appropriately strict.

Take a look at what EmpowerID just did for a large healthcare portal with over 150,000 users authenticating to the portal via SAML, WS-Trust, WS-Federation and OAuth-based technologies from over a thousand different healthcare groups.

It's an age old question, do you want to go with roles or Active Directory group management?  The answer is, why do you have to choose?  Do both.  Roles and groups.

Let me explain.

Windows uses security groups, there is no getting around that.  You have probably accumulated a ton of these groups over the years (and that's a problem in and of itself, ahem, token bloat).  But, the best part is that roles and Active Directory groups can co-exist and even complement each other.

Roles, and especially dynamic roles, are invaluable.  They exist outside of AD so they can be applied to enterprise authorization for any system, they can be applied to file share permissions, they can be applied to any flavor of LDAP directory or even databases.  They can even determine who can do what to AD groups.

And here's the kicker, you can make a role equal an Active Directory group.  So if you have one specific group that you know is updated (or if you manage that group dynamically) and you want to assign rights and permissions outside of the Microsoft ecosystem, make the membersip of that role an AD group in your RBAC powered metadirectory and you suddenly have an Active Directory group granting permissions everywhere!

This is especially useful if you have invested heavily in Active Directory group management in the past and want to leverage all of that hard work.

Contact us for a demonstration of how to make roles and AD groups live peacefully together.