All-In-One Identity Management and Cloud Security

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

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

Not all applications are created equal. For some corporate apps, everyone should be able to access them.  Some should be restricted to certain users, groups and roles.  Some even more sensitive applications should be restricted to certain users, groups and roles and have a higher standard of authentication.  We call this adaptive authentication.

Let's use examples:

• Corporate holiday calendar:  everyone should be able to access this just using their corporate logon.
• Salesforce.com app:  only users in the sales group or role should be able to access this.
• Financials ERP app:  only users in the finance group or role should be able to access this but you want two factor authentication and/or identity proofing before letting them in.

Single sign-on can and should accomplish all of these tasks.  For number one, it's a simple federation with the app (scenario # 3 in the whitepaper "Top 5 Federated Single Sign-on Scenarios").  For number two, it's scenario 1, corporate login to cloud application, pretty simple to do with SAML or OAuth.

Number 3 is the fun one that requires adaptive authentication for single sign-on.

This diagram shows the workflow used to accomplish this.  You set a level of application security in the SSO systems inventory.  Any application that is over level 5, for example, needs to have two factor authentication integrated into the login.  The user is logging in to the ERP financials system, the workflow checks that they have access and then before allowing authentication, it executes a second factor authentication (something you have to have, not just something you know like a password).

This second factor can be an SMS message, an RSA security token, and even be identity proofing from within the directory (what was your previous job title, what was your hire date, etc.).  Single sign-on is there to make your users' lives easier, but it should also improve security.

Schedule a demonstration of how EmpowerID can accomplish adaptive authentication or read the whitepaper on the "Top 5 Federated Single Sign-on Scenarios" now.

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.