All-In-One Identity Management and Cloud Security

There is no need to choose between RBAC and ABAC.  A case can be made for each individually and certainly a case can be made for RBAC (role based access control) and ABAC (attribute based access control) working together.

RBAC is definable, the user is a member of a role or isn't.  If the user is part of the dental chair warehouse worker role, then they are granted access to resources that role needs.  This role membership handles the user's coarse grained access...what files and folders they can access, in what applications do they have user accounts, what group memberships they have.

Most access can be granted at this level, RBAC can be applied to almost every identity action from role based provisioning to role based authentication to role based authorization to role based administrative policies.

These role memberships are all definable and, most importantly, auditable.  Your audit and security reports will show what roles a user has and, conversely, what users are in each role.  You will have an audit trail of every action these users do via their roles and what each of these roles can do.

EmpowerID grants these role memberships during the provisioning lifecycle process.  As a user is provisioned, the roles are granted dynamically based on attributes in any connected system (HR database, Active Directory, ERP system, union membership database).  This dynamic role membership is maintained during a user's lifecycle as their job title, department or anything else changes, so does their role memberships. 

Users can also request access to roles or request access to a resource that puts them into a role.  Self service role management is powerful if the correct controls are in place, with workflows and approval routing mechanisms.  Temporary roles can also be administered in this way, where a user requests access to a customer folder for 3 days.  And, like all role memberships, it is auditable.  You will know who had what access and when.

But, as we started in this discussion, there is a world where roles are not fine grained enough.  You don't want to have a situation where you create a role for every single possible permutation of access needed.  Role bloat like this would be unmanageable and unauditable.  You would end up with more roles than users.

So, what do you do for the finer grained authorization that you need?  Combine RBAC and ABAC.  A user is a member of a role based on access provisioning policies.  But, at runtime when accessing a resource, you can further define that access by ABAC, checking on an attribute that you know about the user in real time.

Let's use that example of the dental chair warehouse worker.  This worker needs access to a particularly sensitive section of your ERP system to order a gold plated footrest on the top of the line dental chair.  But, your security team insists that the warehouse worker should only be able to access ERP during his shift.

Most warehouse workers exchange shifts, take extra hours and vary their workweeks constantly.  You cannot just make a swingshift warehouse worker role and know that it's accurate for every worker every time.  So RBAC handles the coarse grained permission that our user is a dental chair warehouse worker.  When the worker goes to access the gold plated footrest in ERP, EmpowerID checks that the user's role gives him access, then at runtime, checks the time management system to see if the user is on shift right now.  If so, boom, access.  If not, boom, security alert.

If you tried to manage an example like this with just RBAC, you would have a role bloat issue leading to user and help desk revolt.  If you tried to manage this with just ABAC, you would have an auditor and network performance issue, leading to executive management and user revolt.

A hybrid of RBAC and ABAC streamlines this, gives you the ability to manage most permissions with a coarse grained role and the rest with a fine grained attribute.  EmpowerID is built from the ground up to handle these two concepts together and seamlessly.

Users and their access are inextricably linked.  The National Institute of Standards & Technology (NIST) estimates that users are only 58% productive without their proper access.  So, why are provisioning processes often separate from access governance processes?

It should be an identity ecosystem.  When a user is initially provisioned from HR (or a contractor database or a customer self-registration), you apply an initial role to that user dynamically based on what you know about them.  That role (or roles) determine in which systems the user needs to be provisioned.  An example is: sales rep in Toledo will need an Active Directory account, an Exchange mailbox, an ERP account and a salesforce.com account.

Once that user has these accounts, the user will need to have roles within these applications.  The ability to modify groups, access SharePoint sites, place customer orders, modify CRM records and anything else that is role based.  This is the idea that you are provisioning access and accounts.

Some systems, like your VPN or shared folders or Business Intelligence app, may use AD groups to grant these roles.  And this is why provisioning access goes beyond just the application role based access control listed above to group based access control.  No organization can manually keep up with all of the group membership requirements that is required; you need to provision group membership dynamically based on rules and roles. 

Groups are intertwined in your everyday corporate life, from distribution lists to printer access.  However, role based access control is arguably the more modern approach to access governance, reaching outside of the Microsoft ecosystem better and being generally more flexible.  Having group membership controlled by your role makes this easy.

This can all happen dynamically in the first minutes of a user's employment, but users don't sit still for much longer than that.  Estimate vary, but on average, there is a 20% internal turnover per year.  These are employees that are still with the company, but have some sort of job change whether it be a redeployment, promotion, move, or restructuring.  Then the whole identity and access provisioning scenario starts again.

Having a metadirectory sitting in the middle of this identity ecosystem gives you flexibility to inventory HR or AD or any other authoritative source or sources to detect these changes.  Once the change to a user happens, all of the application provisioning can be re-evaluated, de-provisioning accounts they no longer need, provisioning new accounts and changing roles within the applications.

Group memberships get re-evaluated, removing access to old and granting access to new.  EmpowerID can generate reports to show new resultant access for the new roles for auditors or new managers to review.

Then if an offboarding event does happen, all accounts and access are linked to an EmpowerID person object and can be removed in one fell swoop, with accounts de-activated and an audit trail to show access has been removed from everything except their 401K account.

Too often, provisioning is looked at as a way to create an account without considering that access is as important as the user accounts.  Then the lifecycle of the user needs to be considered, again not just as an account but the role and access level required.

EmpowerID's unique visual workflow component, metadirectory and RBAC engine work together as part of the IAM platform to keep privisioning, evaluating and re-provisioning user accounts and access throughout a user's lifecycle.

A pride of lions. A gaggle of geese. A mob of wombats. An Active Directory Security group.  

It’s natural to group things and your users are no exception. Many organizations have more groups than users, a user can be a member of hundreds of groups. We’re talking AD security groups, distribution groups, LDAP groups, SharePoint group, and roles.

We know that 81% of organizations manage these group memberships manually, expending an amazing amount of resources to keep them accurate. If they keep them accurate.

There is something that can be done about it…automate and delegate. Automate the group memberships with dynamic groups. Delegate to group owners the ability to manage their own memberships. Delegate to users the ability to join groups. And put workflow controls in place to keep it organized.

EmpowerID has two methods to manage Active Directory groups dynamically, by roles and by set groups.  The benefit of each is that they can be used across a wide variety of identity and access governance functions: from provisioning to SSO to access control.  And both methods can be used to manage Active Directory security groups dynamically.

Even using the more advanced method of managing permissions with roles, you will still need AD groups, both security and distribution.  And EmpowerID gives you both of these methods to keep your group membership accurate, dynamically. 

This first video explores how to use the roles that are pervasive throughout EmpowerID's Identity Management suite to keep group membership dynamically updated.

In addition to the role based method, set groups can be created in EmpowerID that will manage the group's membership.  As with roles, these set groups have additional functionality in all aspects of IAM from authorization to authentication.

Group management is only a part of EmpowerID's full Identity and Access Management capabilities. EmpowerID's robust IAM platform is built modularly, so you can solve the business problem of today while laying the foundation for future IAM capabilities. 

Take a look at the dynamic group videos and schedule a demo. Save money while improving security and productivity.

Identity and Access Management is all about the authoritative system.  The identity source of truth.  Most often it is the HR system, but for some very important information it is your users.

What you can't automate, you delegate.  And this is especially true for user identity information such as mobile phone, home address, or other personal identity information.  Your end users know this information, you and HR probably don't.

The solution is to give them Active Directory self service.  Delegate the ability to update pertinent identity information in AD but only the pertinent information.  You will need role based access control to determine what the end user can and cannot update.  Let them view title but not edit it.  Allow them to update their office phone but put an approval workflow in place for their manager or the help desk to confirm it. 

But this information belongs in more places than Active Directory.  If your user updates her home address, that information should flow to your payroll application.  If mobile phone is updated, that should flow to your emergency contact list.  Identity is a lot more far reaching than Active Directory, but AD is the place that your users understand; it's the global address list, they see it all the time.

Some information goes the other way.  Your user gets a promotion and the new title is put into the HR system, that information needs to flow to Active Directory.  That same promotion prompts the user to need access to the customer portal and that information flows directly to that portal, provisioning an account if necessary.

Having a metadirectory functioning in a hub and spoke model allows you to configure these attribute flows easily and efficiently.  The EmpowerID metadirectory gives a visual attribute flow to determine which identity store is authoritative and which is a recipient.  You can also have a "first wins" scenario, taking the last change regardless of which system is the originator.

The metadirectory "hub" keeps a record of all changes, allowing you to audit which system recorded the change, when where and how.  You can roll back changes, apply additional workflow actions to any change, and audit these changes periodically.

The idea of adding a workflow to an automated change might seem counterintuitive but the idea is to have identity controls in place for applications that don't necessarily have controls.  Active Directory is a great example.  If you have ADUC access, you have ADUC access.  You want to have role based access where users can manage some attributes, managers can manage more, the help desk even more, and the admins to have more access.

Having a check and balance on each of those powers is important.  Think about this, the users with the most privilege (domain admins and senior executives) also have the most ability to bypass your security.  If you ran an audit on users with passwords set to never expire, the list would most likely be littered with names from those two sets.  And, they are the users you need the most secure.

So if a change comes from ADUC into the metadirectory on a particularly important attribute (say, relating to password policy), put a control in place.  Have another domain admin approve it even though it was an automated feed.  Same thing for title, kick off a workflow when someone's title change from HR contains VP or "Chief".  This is simple checks and balances just like we all learned in the 5th grade.

The metadirectory gives you an easily managed model to flow identity information to the correct identity stores.  It allows you to automate AND delegate.  And, it enables auditing to a level that native application access won't.

Listening to a Gartner webinar on Identity & Access Management this morning, this line struck me: "Cloud breaks legacy IAM approaches".  Because it is true, most legacy IAM vendors are stuck with old codebases, old products, and components that have been cobbled together to form "frankenproducts".  They have no more chance of seamlessly managing cloud identities than they do of installing and configuring on time and on budget.

Cloud identity management is hindered by these old legacy approaches to IAM.  The industry is, in many ways, in the exact same position as it was ten years ago with on premise applications.  The solution to each cloud problem (SSO, provisioning, access governance) is met by a different vendor, or a different product within the legacy vendor's "suite".

In the webinar, Gregg Kreizman says that the larger vendors "have been able to provide functionally across the IAM function set through acquisition, through some development.  They have slowly and somewhat shortly have been incorporating these things into suites, some of them very loosely integrated some of them better than others."

The problem, though, isn't the legacy IAM vendors.  The problem is that it's easier to justify a legacy IAM vendor to your CFO, despite the higher cost and lengthy deployment.  Gregg also says, "I hope no one would base election or implementation decisions based on identifying the largest vendors only."  For the exact reasons above.

Because there are approaches to the cloud that isn't burdened with tons of legacy baggage.  To a newer, more modern IAM platform, that cloud application is just another identity store.  In some ways, even easier to work with due to its requirements for SDKs and APIs.

Having a platform that integrates easily between cloud and on-premise brings you up to date in Identity & Access Management.  EmpowerID has connectors to most major cloud applications and a flexible connector platform to build new ones for others.  Provisioning, deprovisioning, updates are all seamless and fit into your IAM workflows the same as an on premise application.

But that isn't what breaks most legacy applications, it's the integration of IAM functionality.  Provision a cloud user AND provide cloud single sign-on.  Role based provisioning for cloud applications that integrates with role based adaptive authentication for cloud applications.  These are the things that test your ability to manage identities in the cloud.

Chances are the legacy IAM "frankenproduct" cannot do that for on premise applications, much less the cloud.  The only way to make this sort of modern IAM functionality to happen is to have a purpose-built, single codebase IAM platform.  One that can easily have the roles engine speak to the workflow engine speak to the metadirectory.  One that can insert a second factor authentication shape into an access authorization workflow.  One that can provision any number of cloud or on premise applications within a single visually based workflow.  In short, EmpowerID: the modern IAM approach.

That is a list of the capabilities of EmpowerID.  The same platform manages all of this functionality.  What changes is the workflow shapes (think of them like identity management actions) that are exposed by module.  For example, if you have the User Manager and Group Manager modules, you can insert a dynamic group membership provisioning shape into your user provisioning workflow, allowing provisioning to extend to groups.  If you have User Manager and SSO Manager, you can check a user's role and demand additional authentication before passing them along to the cloud application if the role and application mix is identified as highly secure.

The cloud doesn't have to break your IAM.  In fact, IAM is too important to let it.  What you need is an approach that is modern, flexible and built to manage change in both identities and your business process.  Seeing is believing, we can demonstrate IAM that extends seamlessly to the cloud with EmpowerID.  Schedule a demo and you will never think about going back to those legacy IAM approaches.

Windows has created a false premise that the best way to manage shared folder permissions is with groups.  You grant access to the folder by way of an AD security group, then users request membership in that group.  That's the way NTFS works but is it the way users think?

Users want access to a resource; they want access to a folder.  They don't want membership in a group.  Of course, they need membership in a group, but they don't know that.  So, why would you force users to ask for access in such a roundabout way?  It should be simple and the mechanism of how it is happening in the background shouldn't matter to your user.  The premise is: users will think of what they want access to and should be able to request it directly.

EmpowerID File Share Manager puts a 360 degree view of file shares in front of your user.  They can view what roles and/or groups they are a member of and see the resultant access to shared folders.  Or they can view the shared folders they have access to and see the roles and or groups that make that happen.

And, most importantly, they can search on folders to request access.  When they request access a few things happen unbeknownst to them.  If they are allowed access directly, they are granted access.  If a resource owner needs to approve access, it will route the approval to the owner and let the user know that it needs an approval before granting access.

EmpowerID does this by putting a user into a role which has access to that resource (shared folder in this case).  By putting the user in a role and not an AD group it saves the user from being a member of too many groups and ultimately getting token bloat.  Token bloat seems like a made up malady but it is bad.  The more groups your user is in, the larger their token gets.  At 1015 memberships, the token exceeds allowable size and the user cannot log in.  As it gets over 256 memberships, authentication slows down and kerberos has a tendency to lock up with some applications.

So, by managing your shared folders with a dedicated self service portal, your users will have greater and easier access to shared folders, request access in a more intuitive manner, control harmful afflictions like token bloat, and reduce your dependence on an outdated technology like groups.

But you really don't stop there.  That same self service portal can be used by the resource owners to see who has access to their resources (even if granted via groups the old fashioned way).  They can grant and revoke access to their folders either by searching from the user or the resource.  Most importantly, they can attest to the correct access from the resource side on a regular scheduled basis to meet auditing requirements.

Speaking of our friends the auditors, they might be even more resource oriented than the users.  They need to track who has access to a resource and it costs you money and time to have them try to disentangle all of the resultant access from nested groups.  Having them look directly at the resource is, after all, what they need.

Think about the problem of groups from their perspective.  If a group is giving access to a shared folder, what happens if you're also using it for another purpose and people just keep getting added to it.  Your auditing friend wants to be able to see that easily.  EmpowerID solves that issue in another way, too. 

We use hidden system managed groups and use them in a way that maximally reduces token bloat.  The goal is to reduce the number of groups created to assign permissions and to completely control the membership of these groups so people can’t use them for other purposes and add members which would inadvertently grant access to the folders.  We reject any outside additions or deletions of user to these groups.

The debate has raged for years on groups vs. roles, especially with regard to Active Directory and Windows permissions.  The answer is easy: using groups is the old way; using roles is the new way.  Using groups is letting the technology manage the way you do business.  Using roles is making the way you do business lead the technology.  Especially with shared folder permissions.

What goes up must come down.  For every action there is an equal and opposite reaction.  Every user provisioned is eventually deprovisioned.  It's the circle of identity, a term I just made up.

At its core, the concept is simple.  In practice, it is a lot of work.  Microsoft published a statistic at one point that the average user is provisioned in 16 directories when hired yet only deprovisioned from 9 upon dismissal.  That is 7 directories worth of identity floating around your enterprise for a user that doesn't exist.

Provisioning has to be automated and deprovisioning has to be tied to that process.  The obvious automation that you need is to have both processes tied to your HR system.  The logic is simple, if you have a hire date and no fire date, you should have a user account.  But the flaw starts when you have multiple connected systems, both cloud and on-premise.

If you were hired as the receptionist, got promoted to a coordinator and ultimately a manager, you should and will have different accounts in different applications for each of those stages of your career.  Upon your termination date, your identity management system needs to know which accounts you currently have to properly deprovision you.

In effect, you need constantly updating role based provisioning to keep up with your ongoing provisioning and deprovisioning needs.  These roles will constantly update not only your resource access but your application access as well.  Think of it like a key ring, take the old ones away when you add new ones.  You are much less likely to have those extra 7 accounts on your last day.

To keep all of this in synch, your identity platform needs the concept of a person account which joins all of your user accounts to you.  EmpowerID's metadirectory performs this function giving a full view of all of a user's accounts tied to their person record.  So after the three promotions and constant turnover in that user's lifecycle, upon their termination date, you have a clear record of all application accounts, and can deprovision ALL of them, both on premise and cloud.

Think about this term: lifecycle.  Because not all users are managed by a set of hire/fire dates.  Contractors, temps, external partners, customers.  HR cannot be expected to keep a good record of the hire/fire dates of these users, yet they still need access.  Again, not just to the network but to individual applications.

The EmpowerID metadirectory allows you to put start and end dates on any access to any resource, keeping the access from living forever.  Upon hitting the end date, simply renew or let the access expire.  The same thing applies for attestation, you can have the owner of a resource attest to all users who need access.  Or you can have the owner of the identity (manager, account manager, etc) attest that the user still needs each level of access granted.

The metadirectory's join engine and provisioning and deprovisioning workflows automate provisioning and deprovisioning.  The attestation policies keep exceptions from slipping through the cracks.  This keeps the user account store from going up without going down.

If you want cloud SSO, you need cloud provisioning.  This isn't a brilliant revelation...your users can't log in to an account they don't have.

Let's take my favorite and most frequent use case: the wild world of Salesforce.com!  You want your users to be able to authenticate into salesforce without having to re-enter credentials or, worse yet, enter a completely different set of credentials.  So you federate with Salesforce.

Your user authenticates into the network using either her Active Directory or EmpowerID credentials.  She clicks on a link to salesforce and it quickly and invisibly redirects to the EmpowerID Secure Token Service which sends a SAML token to Salesforce which then accepts it and our intrepid user finds herself in Salesforce authenticated and ready to do work.  Without entering any additional passwords or user names.  Like magic, sweet federated magic.

The trick to this is your user needs a salesforce account.  And EmpowerID (or any other identity provider) needs to know what that user's account is.  Without automated cloud provisioning, do you manually provision each account?  Do you have each user claim their account to register it?  Do you put users in AD groups to establish access and hope against all hope that that group stays accurate?

Or do you integrate cloud provisioning with cloud SSO?  This way, users are provisioned and de-provisioned...automatically associating EmpowerID (or some other identity store) accounts with the Salesforce account?  Giving them the SSO experience when they should have it and removing that capability when they should not.  And, reducing the steps needed for users to get this capability.

So, what about existing users?  Do you have each user go and claim their account?  Users hate to follow IT instructions, we all know that.  So let's inventory salesforce.  All you need is a key (such as email address, conveniently your salesforce user name) and you can associate each of your corporate accounts to their salesforce accounts.

And the result, cloud SSO.  And made all the easier because of the connection between cloud SSO and cloud provisioning.  I have written extensively about this, about the connection between all aspects of identity and access management.  You need your provisioning to interact with your access governance to interact with your authentication to interact with your password management. 

IAM is a complex beast to slay, especially with the newer cloud aspects of today's world.  Having a complete platform that can be implemented in phases but still work together solves this and makes this beast much more manageable.

Let's start with the cloud.  Let's get your cloud SSO and your cloud provisioning working together.  Take a look at the federated SSO whitepaper and then schedule a demonstration of how EmpowerID will get your users provisioned and SSO'd to the cloud.

The average user in a medium to large enterprise has 16 applications that they need to access to do their job.  This means 16 username / password combinations.  Doing the math, this translates to a metric boatload of help desk calls to support this many passwords.

There are three things you can do about this:

1. Provide single sign on (SSO)
2. Provide self service password reset
3. Synchronize passwords between the applications

There are advantages and limitations to each option.  Single sign on is probably the best solution, having your users log in once and then be authenticated into each application.  However, if the application doesn't support federation, you will need to do password vaulting and you still have the problem of a lot of passwords.  Many legacy systems will have this limitation.

Providing self service password reset is also a great option.  It allows you to delegate changing passwords once forgotten and can have built in security like two factor authentication or forced enrollment.  But, you're supporting 16 applications and you might as well fix the problem before the horse leaves the barn.

That brings us to password synchronization.  You will give your user a single password that is the same for each application.  When they change it in one place (for example, Active Directory), it will be synchronized to each application.  Users will still need to enter a password each time, but they only have to remember 1 not 16.

Before I go any further, the same EmpowerID module for password synchronization also provides self service password reset, giving you option 2 & 3 in one fell swoop.  Since EmpowerID is a single code-base platform, EmpowerID SSO Manager also can work in conjunction with Password Manager to provide all three options to work together.

EmpowerID is a hub and spoke model, with a metadirectory sitting squarely in the middle keeping identity data and passwords synchronized.  You will most likely have a source of truth for the password, whether it be the EmpowerID directory or Active Directory.  Once this password is changed, EmpowerID will write out that password to all affected applications using stored procedures or APIs. 

If there are different password complexity requirements, EmpowerID can enforce the most restrictive and ensure that the user has a single password for all applications.  If there are mutually exclusive password policies (no special characters in one but special characters required in another, we should explore single sign on).

The first question is usually, what starts this process?  How can you synchronize a password if it is encrypted in the source of truth directory?  We can't, nobody can.  We need to force the synchronization process to start by changing the password initially.  Once EmpowerID has the password, we can follow the security guidelines of each application to synchronize the new password to these 16 applications.

The simplest way to do this is to force the user to change their password on the next login, whether it is to EmpowerID or to Active Directory.  This setting is easy to turn on and gives the user an easy way to create the new synchronized password.  We can also build the password change action into any authentication workflow or give them the requirement to change the password x days before expiration.

But we haven't really saved IT a lot of time yet unless it's easy to implement and configure.  That's where EmpowerID's visual workflow comes in.  Every identity action your users take goes through a workflow which can be customized and personalized.  For our password example, this means that for users with more highly privileged access can be forced to change passwords more often or to also need two factor authentication with OATH tokens. 

This workflow maps to your business process and gives you flexibility in how you manage your passwords and users, giving different policies for different roles or applications.  In short, it makes password management flexible.

But once the users have a single password, the metric boatload of time saved by IT can go towards the single sign on (SSO) project you've been looking at. 

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.