All-In-One Identity Management and Cloud Security

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. 

Prior to The Dot Net Factory, I spent over six years helping healthcare organizations implement software solutions.  During that time I helped doctors, frontline care workers, financial staff, even maintence staff to replace paper documentation systems with electronic documentation solutions.  Now my time in Identity & Access Management (IAM) has helped me to bridge the gap between healthcare and IAM.  Here is a list of common complaints that I heard in the healthcare world:

• Why do I need another system to log into or remember a password?
• Who will setup the permissions for the solution – with HIPAA requirements they must be accurate and up to date?
• What if I am locked out and I need access now?

Another Password or Another Sign in!

As a healthcare professional your job first and foremost is to care for your patients, individuals, & residents.  This means that making sure that Sally gets her medications is your first priority but unfortunately if it doesn’t get documented then it didn’t happen which can setup you up for a costly error that can mean legal or survey errors in the future.  Then what if you need to check her blood pressure before giving the medications and that needs to be input to a vital system?  Now we have two systems that need to be accessed to input one interaction with a patient. 

Enter – SSO (single sign on), now staff can log into Windows, an EHR, or any other trusted app once and then EmpowerID handles the heavy lifting of making sure everyone get access to all of the apps you need without logging in again.

Providing the Right Access

You are a complicated healthcare entity.  You may have a doctor’s office, skilled nursing homes, a hospital, or you provide home healthcare.  You could also be one entity with several wings or units.  Your staff needs access to only what they need and nothing more in every system to avoid HIPPA concerns. 

EmpowerID's Role Based Access Control (RBAC) engine can pull from your HR system to assign the right access to the right people because we know that Sally is a Nurse Supervisor on the Alzheimer’s unit.  Those two things tell us who she manages, what she controls, and what she needs access to.  Your healthcare apps already filter by service location or healthcare unit.  Wouldn’t it be nice to have EmpowerID put them into the correct place at the correct time? 

Access Now!

Your patient is complaining of extreme pain and we must move him from outpatient service to the emergency room, now!  You are ready to take him but you know his daughter was in just earlier today and she needs to be contacted. You need to access your patient’s emergency contact information to see his daughter’s contact information and right as you go to access it you realize that you ignored your email that said your password would expire about 10 minutes ago (of all the moments). 

This particular app doesn’t support self-service password reset  so you have to submit a ticket or call the help desk to get access.  Or even worse you know a friends password or you can have your friend access the information for you (even though it is your patient and not his!).  With EmpowerID’s Password Manager we can give you the tools to reset the password on the fly.  And if you reset your password once it will push the change to all of your apps.  You will answer a series of questions that only you know the answer to; the best part is that EmpowerID can force you to enroll in the password reset system..  This ensures that when you are in this bind you are setup to take care of it quickly. 

These are only a few scenarios but Healthcare systems require so much complicated access and are used so frequently and with so much urgency that access has to be easy on your workers.  Anything from clocking in through one app to giving patients access to their health record from another app or accessing a client’s medication allergies makes things more of a challenge.  That is why our full IAM suite allows you to address one issue or all of them through one platform.

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.