All-In-One Identity Management and Cloud Security

The SharePoint 2013 People Picker is the tool you use to find and select users, groups and claims to grant someone a permission to a site in SharePoint.  The SharePoint 2013 People Picker is heavily dependent on how authentication is configured for your site so you need to ensure your SAML or claim provider is intelligent.

All claim providers created equally!

Today the most common issue SharePoint administrators find with an authentication claim provider is that any name you type in the People Picker, SharePoint will accept.  Even worse, with a typical claims provider you can type nonsense and you will see two results, neither of them valid!

Credit:Kirk Evans Microsoft Blog

This is not because the SharePoint People Picker needs to be fixed, it's working as designed, it is a result of the claim provider.

The EmpowerID SharePoint Manager solves this problem, we have created the most intelligent claim provider in the market today.  In doing so we set out to do 4 things which will have a huge impact on the day to day operations of your SharePoint site.

1. Create the most intelligent claim provider in the world.  We didn't stop at providing intelligent responses to the query, we also segregate the data so that delegated administrators can only view results for data that they can see.  This is a very important point, if a business partner administrator wants to grant someone rights to a site the EmpowerID data filtering and masking is still maintained.

2. Provide SharePoint "web parts".  This is technology that allows users to find new sites and request access to it.  It also allows site administrators to approve site access, all directly within SharePoint.
3. Fully support federated or claims based authentication into SharePoint.  Users can authenticate with EmpowerID, bring their own social identity or use another.

4. Answer the "Why" question.  Why does someone have access and when was it granted?  The other side a SharePoint claim provider is tracking these finer details.  EmpowerID includes full certification and attestation for SharePoint access, this provides your enterprise with a host of risk controls not previously available.

Want to know more?

Watch a previously recorded webinar that discusses these points here

click the button to request more information.

SharePoint permissions do not have to be managed with SharePoint groups, those lonely unmanaged completely removed from the rest of the enterprise collections of users.  SharePoint has evolved to first accept Active Directory groups for permissions and now to accept roles via a claims provider.

Claims providers created in SharePoint can be used for adding claims to the security tokens of users when configuring permissions on secure objects like lists, sites, items and documents.  When EmpowerID is the claims provider, it provides its dynamic polyarchical roles as a selection in the SharePoint People Picker.

How is this useful?  Well, it's a lot easier to manage EmpowerID role memberships than SharePoint or even AD groups.  EmpowerID roles can be managed dynamically by any attribute in any connected identity store (Active Directory, HR, CRM, ERP).  Role locations as well can be mapped from any connected application so a user in the London OU in Active Directory will be mapped to the London role automatically.

By having management roles (the user's job(s)) and location in separate trees, you can define permissions very granularly.  For example, you may only want IT managers in London to have access to the SharePoint site to review IT tasks in London.  You simply pick from the two trees to get IT Admins in London.

You can even add a runtime decision by incorporating Attribute Based Access Control (ABAC) into the equation if you want to check your timecard system to only allow on-duty IT Admins to have access!

The advantage to all of this is that user's permissions are not static.  Conservative estimates say that internal turnover is about 20% per year, meaning that 1 in 5 users will change jobs.  Think of the last time you updated a SharePoint group....it is certainly not that often.  Roles, however, are dynamic, reading from attributes that flow from within HR or any other authoritative source.  If that IT Admin makes the mistake of starting in sales, she will automatically have her IT admin role revoked and new sales role(s) invoked.  Permissions will change without IT having to lift a finger.

Check out our whitepaper on dynamic roles or schedule a demonstration of EmpowerID and see how it can increase your security in SharePoint without having to mess around with SharePoint groups!

Looking at the title of this blog post, you would think, "that's crazy, there are no roles in SharePoint!"  Microsoft liberally uses SharePoint groups to mean roles in their documentation, but these groups aren't useful in any RBAC manner beyond SharePoint.  SharePoint can also utilize Active Directory security groups, but there is a downside to this with token bloat and the accidental mixing of permissions between SharePoint and AD (add a user to a group to grant access to a SharePoint site accidentally gives them access to the deepest darkest secrets in accounting).

Groups are not roles.  Especially when they are static by nature.  Over 85% of organizations manage groups manually, you can never really be certain that the correct users are in the correct groups if that is the case.  You need your roles to be dynamic and rule-based.  You need your RBAC to be augmented by ABAC for on the fly fine grained permissions.

So, how do you do this in SharePoint?  By setting EmpowerID as your claims provider. SharePoint Claims providers add claims to the security tokens of users when configuring permissions on secure objects like lists, sites, items, and documents.

This gives you the ability to expose your roles in the People Picker to find and select people, groups, and claims when a site, list, or library owner assigns permissions in Microsoft SharePoint Server 2010. When claims-based authentication is used, the People Picker allows end-users to search and select claims for permissions assignments from a custom Claim Provider or Claims Augmentation provider just as they would normally search for users or groups. Typically a Claims Provider would support more flexible role-based assignments or dynamic fine-grained authorization assignments to increase the flexibility and security of the SharePoint permissions system.

In EmpowerID's RBAC engine, roles are assigned dynamically, either by set groups or a role structure (location/department, etc).  The role structure is polyarchical and is generated based on your applications and corporate structure.  Powerful RBAC policies leverage EmpowerID’s multi-tiered model to pre-calculate access to all known enterprise applications and resources based on an organization’s structure, a person’s job function, and all directly assigned access. These rules allow information from authoritative systems to drive changes in application access and provisioning policies.

What you end up with are roles that can be applied to any application, access or provisioning policy.  The role membership is updated dynamically based on changes in identity information from any connected identity store (HR, customer database, Active Directory) and inventoried as often as every couple of minutes.  And, very importantly, used to manage SharePoint permissions without having end users have to manually update AD or SharePoint groups. 

Think about that, SharePoint permissions that stay accurate without you having to manage it!

These permissions can be assigned as Administrator, Contributor, Reader or any level of access within SharePoint.  When the user signs in, the EmpowerID claims provider will pass along a claim with all of the user's permissions within SharePoint.  You can even use EmpowerID for SharePoint single sign-on for external or internal users.  The same process applies and you won't have to give an AD account to the external user.

Make SharePoint work by managing SharePoint roles dynamically.  If you want a demo, we would be happy to show you how this works by clicking here.  Or click the button below for a whitepaper on our method of managing permissions with an RBAC / ABAC hybrid.

For years I've been engaged in the debate over using SharePoint or Active Directory groups for SharePoint permissions.  There are pros and cons to each and I am pretty sure there is no perfect answer to which is better.  However, I am pretty sure that role based access control to SharePoint solves the issues with both types of groups.

Here's why: you don't get token bloat with roles, you can create dynamic roles, you can run self service workflows for users to join roles, you can delegate role membership management to users, and you can use the roles for almost any other identity action.

EmpowerID makes role based SharePoint permissions possible by being a SharePoint Claims Provider for SharePoint 2010.  As the identity provider for SharePoint, EmpowerID will pass a token that has all of a user's claims including both authentication and authorization.  This means a user is authenticated into your network and navigates to a SharePoint site; SharePoint will check with EmpowerID to see if that user exists and what access she has.

Using WS-Federation, EmpowerID's Secure Token Service sends a token to SharePoint to authenticate that user.  In addition, any additional authorization claims are embedded into the token so that the user has access to all of the sites that she should.

As the claims provider for SharePoint, EmpowerID's roles are inserted into the people picker for site owners to provide access.  They see these roles right next to users and groups.  If an end user wants access to a site, they can request access and EmpowerID can assign them to a role (depending on approval levels of course).

That's how it works but the magic is in defining the roles for the user.  EmpowerID roles can be managed dynamically or delegated.  The majority of roles are going to be based on our polyarchical system and dynamic.  If you are in XYZ department in ABC location, you are in the XYZ role, the ABC role, and consequently the XYZ-ABC role.  This keeps the number of roles from getting bloated, having to create one for each management role/location combination.  These management roles can be based on any criteria: business unit, department, title, whatever fits your business.

Users can also request role membership.  The EmpowerID workflows to make this happen can require varying levels of approvals based on who is requesting and what they are requesting.  Some are automatic (book club member) some are severely restricted (earnings committee).  The self service interface can be via EmpowerID or exposed in SharePoint.

Lastly, each role has an owner or owners who can manage the membership, either for approvals or to directly manipulate the membership of the role.  Any role membership can be attested to, can be made temporary, or can require approvals.

Back to the SharePoint site owner, she doesn't have to worry about the membership of the roles.  The three methods above of managing membership means that she just has to worry about which role should have access.  Remember SharePoint groups are static and require manual intervention.  AD groups' membership cannot be viewed in SharePoint so the site owner has no idea who she just granted access to.  Each of these concerns is addressed with an EmpowerID role.

SharePoint is an invaluable tool for your business but managing it from within IT is burdensome.  Too often, SharePoint is configured and accurate on day one and the permissions slowly deteriorate as site owners manage access manually.  Fix this for them.  Manage roles for your entire identity ecosystem and provide these roles to site owners to manage their site's access.

EmpowerID's standards based approach will give you SSO and role based SharePoint permissions.  It is easy to manage and even easier once you start delegating.  Your SharePoint implementation will become more robust and useful.  Schedule an EmpowerID demonstration and see for yourself how your life can be easier.

The bane of every SharePoint project is permissions and rights.  Access is controlled via SharePoint groups, these quirky little groups that exist in the SharePoint vacuum and only in the SharePoint vacuum.  SharePoint 2010 introduced the ability to control access via Active Directory groups but gives no way to manage the membership of these groups.  So you end up with site admins managing permissions manually or just letting it die on the vine.

What if you could do true role based access control (RBAC) within SharePoint?  Have dynamic roles for your users that change as the user changes (new department, title, location, etc)?  And then manage site permissions with these roles?  Thanks to SharePoint 2010's claims provider functionality you can.

If you set EmpowerID as the claims provider for SharePoint, it exposes EmpowerID roles in the "People Picker", allowing the site administrator to pick a role (for example, HR managers in the investment banking division) to have access to that site.  These are the same roles that will be used for resource permissions or application access.  And it is possible to see who is a member (if you have permission to view membership of that role) from within SharePoint, making it possible to ensure that the right people have access to the right SharePoint resources.

The thing about roles is that they don't have some of the side effects that Active Directory groups do such as token bloat.  You can be a member of as many EmpowerID roles as you want without impacting your ability to log into the network.  On top of that, EmpowerID offers a polyarchical role structure so you can pick that HR manager role in investment banking from two trees, limiting the number of roles that you need to create.

Having a true SharePoint RBAC system also allows you to manage separation of duties since you can set an SOD rule that says a user cannot simultaneously be in two conflcting roles.  You don't have to worry about accidentally giving an investment banker access to the retail banking SharePoint site.

SharePoint RBAC is just a lot more flexible than managing permissions with groups (either AD or SP).  You get all the benefits of maintaining permissions dynamically without the overhead of managing a completely different set of access infrastructure.  This same claims provider functionality gives you SharePoint single sign on capabilities for your external partners for example without having to have AD accounts for them.

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!

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.

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.