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.

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.

While having a discussion with a partner this week, he pointed out that enterprise single sign-on and federation are being confused much less often these days.  That led me to asking a few people what the difference is and finding that there is still confusion about the two.

So what is federation?  And how is it different from Single Sign-on (SSO)?

SSO is an umbrella term for any time a user can login to multiple applications while only authenticating once.  It covers both federation and password vaulting which is more commonly known as “Enterprise SSO”.  The main difference is that federation eliminates the requirement to use and remember passwords and Enterprise SSO doesn’t.

Federation allows single sign-on (SSO) without passwords – the federation server knows the username for a Person in each application and presents that application with a token that says, " this Person is domain\johndoe or johndoe@example.com".  No password is required for the user to login to each system.  Because of the trust between the two systems, the target application accepts this token and authenticates the user.

The federation server passes that token using one of the standard identity protocols: SAML, OpenID, WS-Trust, WS-Federation and OAuth.  The benefit to federation is security and authentication into both on premise and cloud applications.

Enterprise SSO is when the applications all still require that a password be sent to login, but the software handles storing it and automatically retrieving it for the user and inputting it into the application for an automatic login. The user still has a password for each system that must be provided to login, must be changed on a regular basis, etc. 

I like analogies; in my mind, Identity federation is like an amusement park.  With Enterprise SSO (ESSO), you get into the amusement park but still need a ticket for each ride (think Santa Cruz Beach Boardwalk).  With federation, you get into the amusement park but have a wristband that every ride operator recognizes and lets you on (think Disneyland).  Feel free to use this one.

Even understanding this distinction, there are a lot of different implementation scenarios depending on whether you are initially authenticating on network or in the cloud, whether you are signing in to cloud or on-premise apps, or whether you want to manage Identity as a Service (IDaaS).  Download our whitepaper on the Top 5 Federated Single Sign-on Scenarios to see which one best fits your requirements.

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.

For years and years,Microsoft has been recommending AGDLP as the way to manage your file system permissions.  User and computer accounts are members of global groups which are members of domain local groups that give resource permissions.  This is, to put it mildly, the old and busted way of doing things (OBWDT for short).

And here is why: try telling me who has access to that file.  You know, a user who is nested within a nested group that nobody knows who manages.  In fact, you don't even know the last time that group was updated.

So, how do you solve this?  True role based access control (RBAC for short).

If you are doing RBAC correctly, you have a metadirectory that is assigning roles dynamically or statically to your users.  These roles are granted access to resources.  Your RBAC-based file share manager will continuously  inventory and monitor for new shared folders and follow a workflow to give the appropriate roles access.

Here's the other side of the coin.  A user knows about a shared file or folder and wants access; I saw this use case on an IAM board on LinkedIn today in fact.  How does that user request access?  Does he or she have any idea what group or groups manage access?  No.

Why not give an easy self service format for the end user to request access to the folder that is routed to the correct approvers?  Without the end user needing to know a single thing about AGDLP or other technical nonsense.  RBAR (rights based approval routing) to the rescue.  This workflow knows who can approve and how long that user can have access.  A top secret folder being accessed by a contractor, give them access for 3 days, no longer.

Just because Microsoft (MSFT) recommends using an old and busted technique (OBWDT) like AGDLP shouldn't stop you from looking into RBAC to properly solve your file system permissions issues.  Schedule a demo ASAP.

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!).