All-In-One Identity Management and Cloud Security

SharePoint's People Picker is one of the strangest user interfaces in the world.  A SharePoint site admin generally gives permissions to either SharePoint groups or Active Directory groups.  But if he/she uses AD groups, he/she doesn't know who is a member.

You can solve this conondrum with dynamic Active Directory groups but that still falls short.  Active Directory groups have all sorts of issues with forests and domains and what if the user doesn't exist in AD?  Many SharePoint instances are a combination of access for employees, contractors, partners and customers.  It would be nice to manage the SharePoint permissions for each of those in one central place.

Luckily, SharePoint 2010 supports an external directory as a claims provider.  EmpowerID's metadirectory functions as the claims provider and offers federated single sign on to SharePoint.  And this opens up the world of roles (static or dynamic roles) to SharePoint.  SharePoint permissions management becomes more robust as you can have roles in EmpowerID that reference any identity store, not just AD.

EmpowerID’s powerful hybrid RBAC and ABAC model can be used directly inside SharePoint’s People Picker user interface to grant access to sites, lists, documents, etc. The People Picker allows end-users to search and select any EmpowerID security object such as People, Groups, Roles and dynamic collections just as they would normally search for users or groups.

The EmpowerID RBAC system allows content owners and security administrators to use flexible and dynamically maintained role-based assignments when managing SharePoint permissions. The dynamic nature of these roles can dramatically reduce the administrative burden of manually setting security assignments and automates access granting and revocation based on changes in user’s job status, function or location.

Role based access control (especially when mixed and matched with attribute based access control) gives SharePoint a ton of flexibility in how you assign permissions within SharePoint.  That customer can get the exact access they need (and even SSO) without lifting a finger.  Your SharePoint team can publish internally and know that role based permissions are keeping it safe.

This is all built-in functionality to EmpowerID, let us know if you'd like to see it in action!

Talking to a client the other day about enterprise to cloud access, it became apparent that before considering cloud SSO, cloud provisioning needed to be taken care of.  More than that, role based cloud provisioning.

And this is where it gets tricky in the IAM marketplace.  There are a few companies offering cloud single sign on and doing it well.  They just don't have the platform in place to integrate with the on premise world and do role based provisioning to the cloud as part of that solution. 

And, think about your business goal here for a second.  You want to make sure that the right users have the right access to the right applications.  So, first you need to do role based provisioning; anyone in sales and support needs access to salesforce.  Only those users should be provisioned; after moving to another department they should be deprovisioned.  Data security is one thing to consider but so is license consumption...you pay monthly for these licenses.

Once you've provisioned the correct users to the cloud application (in this case salesforce), you need some role mapping.  That sales rep should have different access than the sales manager than the support rep.  Map your corporate roles to the cloud app role and not only do you get user accounts for the right folks but they get the right access.  As they move jobs, the dynamic role in your enterprise directory maps to the cloud role and presto boomo, accurate access to cloud applications!

And, now for the thing that people worry about.  Cloud single sign on...federating with the cloud application.  This is arguably the least important step but the one that gets the most attention.  Who cares if you only need one password if you have the wrong users getting access?  Luckily, it's possible to do all three and leverage the same directory if you can do SAML federation from the directory that is handling the cloud provisioning and access.

There must be others doing all three aspects of this cloud provisioning, but if any of this rings true to you, schedule a demonstration of EmpowerID and see how to get the right users the right access to the right cloud resources, and SSO them while you're at it!

If you are going to adhere to the principle of least privilege, you also need to consider temporary privileged access.  The idea is that a user and/or administrator should not always have privileged access but will probably need it for a short amount of time.

To do this, you need a few things:

1. a mechanism to request access
2. a workflow to approve the request either by business rules or user approval
3. a mechanism to grant and revoke access in a specified amount of time
4. a mechanism to extend the privileged access
5. a mechanism to audit and report on this access and
6. a "break glass" method of emergency access

In short, you need a robust role based access control (RBAC) system.  If you have all of these pieces you can avoid the inevitable outcome of the off-duty admin saying, "OK, just this once, use my credentials"!  Yes that happens.

Let's think through a use case.  Your internal developers have created a web app that is crashing, they don't have access to production but need to run some tests and troubleshoot what has happened.  They could work with an IT admin and get it done using their credentials but that doesn't always work.

So, they go to their access request portal and request access to the production system.  Based on their role or admin approval, they are either immediately granted membership in a role for 24 horus or a one time password (OTP) that expires after 24 hours.  Either way, steps one through three are achieved.  The developer has access, it's been approved but it's going away in a specified period of time.  They get to work troubleshooting.

One day later, they are still working at it and get a notification that their access is about to expire.  They apply for an extension and it invokes the workflow again.  Maybe this time, the request needs a VP of IT approval regardless of the role the developer is in.  The workflow should be able to handle any business rule you put around the temporary privileged access.  Still, step four done and accounted for.

And "accounted for" is a great segue to the need to report and audit such access.  If this is a sensitive system, or even if you are just a highly regulated industry, somebody needs to say who had access to what, when and who approved it.  Any changes within that system needs to be accounted for and the auditor will need to know how "developer X" got access.  That's step five.

Now, the tricky one, the break glass method.  Go back to the beginning of this scenario, it's Saturday at 2AM and your revenue producing portal crashes.  Nobody can fix it but the developer and your business rules require a VP to approve his access request.  However, that VP is in Fiji enjoying a hard-earned vacation. 

Having a way to circumvent the normal approval process in an emergency is a must.  The workflow takes a different route if this is deemed an emergency request.  Maybe a director can approve it but it will send red flags throughout the auditing community and require a retroactive VP approval to keep them from sending in the infantry.  This gives the emergency access (you still have all of the auditing of who did what and when from step 5), keeps a strong sense of security, gets the project done and keeps you in regulatory compliance.

This need for temporary privileged access (TPA I guess we could call it) happens constantly.  The workarounds are dangerous from a security standpoint if you don't have a mechanism in place.  The effect on your business is probably worse if you just ignore the need.  And you still stand on the high and mighty pedestal of Least Privilege!

A customer was showing us his current state of role based access control for their business intelligence application.  What had happened was that for each segment of BI reporting, he had to create a role.  The real issue was that each of those roles was needed for each region.  So suddenly he had 10 management roles TIMES 4 regions for a grand total of 40 roles that he needed.  Just for his BI app.

He needed an easier way to manage this.  Their solution had been to allow an EMEA user to request North American access and then the approver had to deny it.  It was confusing for both the access requester and the approver.

What helps this is our combination RBAC and ABAC (attribute based access control) hybrid model.  10 business roles are defined and then access requests are security trimmed based on the requester's region (an attribute in the directory).  Attribute based access control allows you to take an actual role and get fine grained for the access request system without the requester even knowing it is happening.

We could even fine tune it further by using rights based approval routing (RBAR).  Let's say they want to define it that anyone in a certain department gets auto-approved, RBAR does that while still requring approval for someone outside of that department even though they are both in the same role!

Remember that the whole goal of Identity Management is to get the right user the right access to the right resources.  What is left unsaid there is "with as little IT interaction as necessary".  You can add some components like ABAC and RBAR on top of RBAC to map these workflows to your business process.

In the end, the customer won't need to create an exorbitant amount of roles, they reduce the back and forth approval process, and make it easier for the end users.  Then for the auditing and intelligence portion of IDM, you'll have a full report and view into whether a person approved the access or a business policy did.  You will be conforming to least privilige principles by security trimming what a user can even request.

Take a look at this whitepaper if you want more information.  If you are ready to start controlling your access with EmpowerID, we'll show you a demo and prepare a trial for you!

One of the  main issues with access requests by your users is they don't know what to ask for!  Think about it, your user knows that they want to see the prior year's sales results sorted by average receivables age.  They go to your access resource catalog and sure enough there isn't a resource named that.

You and I both know what they want is something called sales manager role in QuickBooks but that translation is not apparent to your user.  How do you solve this?  You can't name your role based on what they want to do because other users in that role have other needs.  You can't necessarily have them ask to mimic Bob in the Scranton office's rights because you might have granted him a higher level of permission (never violate least privilege if you can help it).

Until we can intuitively read the user's mind and translate on the fly, we need a way for the user to understand what they're looking to do and assign permissions for that particular task.

We thnk the best way to do that is with access bundles.  This way you don't have to create a bevy of highly specific roles but you can bundle a bunch of access into an access bundle that has multiple related access rights.

And that's where access certification and re-certification comes in.  If you grant this access bundle to a role, user or group, then they all have it until time comes to an end.  This shouldn't be.  Any access request that is granted needs to be attested to often.  The best recommendation is to grant access for 3-5 days initially, if the user still needs it after that they have to request to renew this access.

This request should kick off a workflow to the resource or role owner to certify that the user, role or group still needs access.  At this point, they can grant access permanently, for a set period of time or deny permission.  This certification process can vary by resource or the role of the user requesting. 

View access as a privilege not a right.  But if you are going to keep this principle of least privilege, then make it easy for access requests and certification.  Next time we'll go over the fun part of designing your catalog of access bundles!

If you want to take a look at how this works, we can give you a demo and trial of EmpowerID, just click the beautiful button below!

There are some things that only your users know.  So why not make them the authoritative source for that identity information?  Some examples would be mobile phone number, home phone number, emergency contact information, and oddball information like shoe size.

Providing Active Directory self service gives you a good place to store this data.  Most of these items have attributes in AD and you can easily synchronize that information from AD to your HRIS or emergency notification system.  You can even then start making dynamic Active  Directory groups based on the information.

But you don't want to open ADUC to just anyone so you need a role based Active Directory user interface for self service.  The reason for role based is you need to have security built in to the self service web page so that I don't go and change my colleague's title.  You'll need to have rights based security allowing a manager to change some fields for their employees and the employees to have access to change other fields.

You then want rights based approval routing to make sure that somebody is there to approve any changes that need approval, whether via email or an approvals dashboard.

We have a whole whitepaper on how to replace ADUC, take a look.

But then there's another issue.  What if Active Directory isn't the place to store the information?  For example, you have union employees who need to update their union membership with HR every once in a while.  You don't want that information flowing through AD to get to your HRIS.

We solve that with a metadirectory.  The metadirectory has pretty flexible attribute flow rules so you can create a self service page using our forms designer, have it update the metadirectory (again, using rights based approval routing) which flows directly to HR without AD being in the middle.  To use technical jargon, presto bammo, you have self service updates without IT having to be involved.

This is probably EmpowerID's most basic and simplest use case, with almost the entirety of this functionality able to be installed, configured and deployed in two hours.  Give us a shout for a demonstration and we'll have you up and running in no time, delivering Active Directory self service for user and group management.

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!