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!

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.

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.

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.