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.

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!

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!

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.

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.

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

User account provisioning isn't really rocket science.  You want users to be able to do their job from day 1.  What you don't want to do is just provision a user account in Active Directory and call it a day.

Remember this stat: a user is only 58% productive without the proper permissions according to the National Institute of Standards & Technology.  So, when provisioning a user, give them more than their AD account; provision that user to every system that they are supposed to be in.  Don't lose 42% of a user's productivity.

Consider what you know about a user from your HRIS: name, department, title, location, shoe size; all the relevant identity information for you to decide their most basic roles (you can determine more granular roles as you learn more about them).  From these basic roles, you can provision them into the correct systems.

To take that identity information and turn it into role based provisioning, you need workflow.  Workflow isn't just approval routing, it is the ability to set a business process within your provisioning and access control.  For example, the first box in this workflow is what location your user is in...depending on location, your user is provisioned into the proper card access system and put into the correct security group for printer access. 

Once that workflow is complete, every user returns to the next decision point based on department.  A user is provisioned and is given access to Salesforce.com if in sales or service, to Quickbooks if in finance, etc.  Of course, you can be more granular but people stop reading blogs if you get into too much detail!

Now the third workflow kicks in based on a piece of identity information not usually associated with roles: shoe size.  Each user/employee is given a pair of shoes for the company's annual Race for a Good Cause.  This is where the ability to have a hybrid of RBAC and ABAC comes in handy.  You want your supply chain software to provision a different color shoe based on departmental role, but also give the correct size based on an AD attribute.  Simple, a hybrid approach to RBAC and ABAC applies to provisioning as well.

Now your user has an AD account and, thanks to role based provisioning, has been placed in the correct systems and security groups, is operating at 100% productivity on day 1, and most importantly wearing the correct color shoes.

Click below to schedule a demonstration of how to manage role based user provisioning and extend it into an ongoing RBAC process.

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.

Role based security means an awful lot more than just role based access control (RBAC).  It means using RBAC to its fullest potential to secure all resources in and out of your network.

This means having an identity management platform that is built on the idea of roles.  Provisioning to different systems based on roles.  Granting access to resources based on roles.  Workflow levels based on roles.  Single sign-on based on roles.  Roles have to be core to the identity and access management platform that you choose.

IdM platforms built from acquisitions and hodge-podged together have a hard time having a core platform belief system like this.  The components need to be able to talk to each other seamlessly in the same language (not just programming language either).  For example, if you are provisioning only certain roles into salesforce.com, then your single sign-on has to understand that role and work with it, only allowing those users to even go through the SSO process.  Otherwise, you get moving parts; Frankenproducts love moving parts, business productivity doesn't.

A great example of this is rights-based approval routing (lovingly known as RBAR).  RBAR unifies workflow and RBAC security to enforce real-time evaluation and routing of who can approve what based on the actual rights delegated to the current person at that time for the affected resource.  Approvals route to approvers with the necessary privileges to perform the intended operation. Those rights are determined by your role.

Using RBAC and Attribute Based Access Control together is even better.  Picture you are in the Sales in Toledo role so you are provisioned into Salesforce as a user.  But you are a manager as shown in your title attribute in Active Directory.  Using the RBAC/ABAC hybrid allows your IdM platform to approve requests around Salesforce access and/or have extended privleges within salesforce.

Take a look at our whitepaper on Best Practices in Enterprise Authorization - the RBAC/ABAC Hybrid Approach.  You will get a great idea of how this all should work with a proper platform built with a foundation of RBAC.