All-In-One Identity Management and Cloud Security

Life would be a lot easier if we only had to manage our employees' identities.  But we have customers, partners, and contractors.  These external identities have the same needs for identity management as our internal identities.  In fact, they might have more needs as we know a lot less about them.

The most common scenario that we see is when a customer (the external user) registers for services with our client.  The needs are very simple: self-registration, role based access control, approval workflows, and federated single sign-on (SSO).  I'm kidding, that's not simple.

Let's start with the self-registration.  When your external user first finds your site, you will want their registration to be simple, giving them immediate access to the most public facing resources.  EmpowerID's built in forms designer allows you to have them fill out the important information and create an account in the metadirectory. 

The RBAC engine will give them the most basic of permissions at the same time that it either kicks off an approval workflow to grant more permissions or inventories another identity store (CRM for example) to determine their role and give higher privileges.

So, now you know who they are and can design some provisioning rules for other applications.  With the roles in place, you know that customers that meet certain criteria get access to different applications and resources.  Role based provisioning will automatically create accounts in these applications.

Permissions are managed with these roles too.  Polyarchical roles allow you to protect resources at a very granular level without having to create a role for every single type of external user.

Now we get to the heart of the matter, you know who your external users are, what their roles are and what access you give each role.  Now your users need to access these resources and applications.

Enter single sign-on (SSO).  You have provisioned a user account in the EmpowerID metadirectory.  This metadirectory can act as an identity provider or service provider, meaning that you can authenticate with EmpowerID and federate out to other applications or you can authenticate with other credentials, federate with EmpowerID and then with your other applications.

EmpowerID as an identity provider is incredibly powerful, it is also a Secure Token Service, allowing it to send tokens to the federated applications and giving users immediate access based on their role.  EmpowerID supports federation with SAML, OpenID, OAuth, WS-Trust and WS-Federation.

For applications that aren't federated, EmpowerID can also perform Web Access Management (WAM), sending user credentials securely and giving the same end user experience.

On the flip side, you can also federate with other identity providers such as Facebook or Twitter, giving users the ability to authenticate with credentials they use every day.  EmpowerID is still in the middle and provides role based access to the connected applications.

EmpowerID is one of the only IAM solutions on the market that manages external users' provisioning, authentication and authorization.  EmpowerID supports anonymous provisioning, allowing users to register for the services and be given a baseline of permissions.  EmpowerID can federate with Facebook, Twitter, etc. to authenticat, claim accounts in other applications and manage any attributes.

EmpowerID can then perfrom two factor authentication, device registration or identity proffing to further confirm the user's identity.  This seamless HTML5 interface works on any device allowing mobile usage and a better overall user experience.

Schedule a demonstration and see how you can manage your external identities, giving them more secure and easy access to your resources.

Andras Cser of Forrester writes that XACML is Dead.  The first analyst question I was asked as head of marketing at EmpowerID was, "do you support XACML?"  The easy answer was (and is), "we will when application vendors do."  Andras' first point as the cause of the death of XACML: "Lack of broad adoption."

Andras' second point is the one that really gets to the technical heart of the matter rather than the logistical: XACMML's "inability to serve the federated, extended enterprise."  Identity and Access Management (IAM) has moved way beyond the borders of an Active Directory forest.  Organizations are managing their internal users, partners, customers, and contractors and need a flexible authentication and authorization system that can accomodate the unique needs of each constituency.

Additionally, the applications they are accessing are growing more varied and widespread.  You have legacy applications, cloud applications, web applications, and mobile applications.  Organizations demand an IAM platform that can authenticate and authorize not against the ones that support a specific standard, but all of them.

So, while some analysts have been trumpeting loudly that XACML is going to make authorization easy and standards based, the market and forward thinking analysts like Andras have realized that IAM in today's world is too complicated for it.

Unfortunately, this leaves us at the question: how the heck do we manage authorization in this new complicated world?  We believe that EmpowerID has hit on the best way to manage it, by integrating roles into every single aspect of IAM from provisioning to authentication to password reset to SSO.  Making your roles pervasive in all aspects of IAM gives you flexibility on the who has access to what and when question.

EmpowerID's role engine was designed as part of a purpose-built single codebase IAM platform; roles fit in as an integral part of each IAM function.  Our polyarchical role structure is flexible and intuitive, allowing organizations a tremendous amount of flexibility in how they apply permissions and authorization.

When roles are too static, we combine ABAC with RBAC to give runtime decisions based on attributes in any connected system, giving even more flexibility.

EmpowerID includes an advanced authorization policy engine that allows organizations to define a user’s access to a diverse set of corporate and cloud-hosted resources via flexible RBAC and ABAC rules. This “resultant access” information is then either consumed or “pulled” by systems that support leveraging an external authorization engine to make access decisions or “pushed” down onto systems that don’t.

Read more about EmpowerID's authorization engine, schedule a demo, or request a whitepaper on Best Practices in Enterprise Authorization.  XACML isn't walking through that door ready to save enterprise authorization, take a look at a solution that will.

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.

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.

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.

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.

Reading an article by Earl Perkins titled Data Meets Applications in Identity and Access Governance, I was struck by the distinction he makes between application and data access governance.  From an IAM professional's point of view, they should be one and the same thing...access to resources for their users.

But, apparently, our competitors haven't always thought that way.  He talks about how IAM suite vendors (we are one) are squeezing out point solutions by buying companies and product lines to integrate data access governance into traditional IAM.  EmpowerID is one step ahead of that curve (at least one step!).

EmpowerID's platform incorporates role based access control (RBAC) into all aspects of IAM: provisioning, authentication, synchronization, and, yes, access governance.  This ability to manage any IAM workflow based on roles or even attributes (ABAC) and integrate them into any IAM process is what makes our access governance abilities unique.

We don't have to distinguish between data and application access when granting privileges.  Either are simply resources to empowerID.  The same role structure, the same access request workflows, the same user interfaces apply whether asking for access to Salesforce.com or that folder in the Windows file system, or the shared Exchange mailbox. 

If your role has access, you have access.  If you want to request access, it is the same UI and a resource-appopriate approval process.

For data access governance, we have taken it one step further.  Most solutions offer you one of two ways to request access: 1) request access to a file or folder, or 2) request access to the group that is granting access.  EmpowerID adds the option of requesting access to a role.

No two users think of this process in the same way.  Those who prefer option 1 think of it as, "I need access to that data", those who prefer option 2 think, "what do I need to get access to data", and the third think, "who gets access to that data."

An access governance solution should be able to provide all three options (within limits of course) to satisfy the left brain, the right brain and the all brain thinkers.  Not just for data but application access as well. 

I dislike square peg round hole situations.  If you consider your access governance and IAM solution to be a peg, make it malleable to fit your own businesss situations, processes and policies.  Let us show you a personalized demonstration to see how empowerID can fit into your business and improve access governance.

The biggest benefit to attribute based access control (ABAC) is its flexibility.  You basically are assigning permissions to anyone who meets a certain criteria.  Dynamically.  As soon as you change a person's job, location, employment status, any attribute in any system you want, you are changing their permissions.

Ignoring application based permissions and roles for a moment because if you are reading this you have most likely seen the light in managing permissions in a centralized manner, there are three other main ways to manage permissions.  Users, groups and roles.  To manage permissions user by user would require, literally, a cast of thousands so we can ignore that one as well.

Active Directory security groups are used for permissions quite often.  File systems, SharePoint and some one off applications use AD groups.  Groups are something your users understand; it's just like a distribution group.  But there are limitations.  Not all applications can understand AD groups.  Maintaining group memberships is labor intensive (unless you use EmpowerID Group Manager!).

But one of the biggest issues is nested groups.  If your application is consuming group membership to manage permissions, it has to reach out to AD every time it tries to determine if your user has access and figure out the resultant permissions.  If you nest too deeply, this can take minutes each time (based on a client anecdote, up to 5 minutes).  EmpowerID solves this by inventorying group memberships and storing resultant permissions in the metadirectory but that's a blog post for another day.

Role based access control is more powerful than groups as you can map roles to any connected system or application.  Roles can be dynamic, allowing you to have the immediacy of attribute based access control.  This means that if someone changes departments, their role changes immediately as well.  These new roles can then be mapped to all applications and resources to reach well beyond the scope of AD groups.

But then you sometimes still end up with the square peg round hole syndrome.  You cannot have a role for every single permutation of permissions needed or you might as well go with assigning permissions by user.  Role bloat can be just as bad.  EmpowerID's polyarchical role structure helps solve that by allowing you to assign permissions based on multiple trees (business role and location for example), keeping the number of roles down.

You can still end up with one-offs and that is where ABAC comes to the rescue.  With EmpowerID's metadirectory, you can assign permissions based on attributes in any one of the connected systems (HR, AD, line of business apps, CRM).  Access rights are constantly inventoried so you don't have to hit each application every time someone tries to use that access, speeding up the time to grant access for the user.

When ABAC works best is when it is utilized in conjunction with RBAC.  For example, you have a sales role for account managers in the national accounts segment.  You want to give access to a sales contest reporting tool but only want it available to account managers that are at over 100% of quota. 

You certainly aren't going to create a "national account manager exceeding plan" role but you will have one for "national account manager".  Have EmpowerID check against your commission database to allow access for National Account Manager (role) who are greater than 100% to quota (attribute) and you have RBAC and ABAC synchronicity.

In summary, ABAC and RBAC are both better than group permissions.  There are times to use RBAC exclusively and ABAC exclusively.  But then there are also times to use them together and solve the square peg access problem.

Take a look at our whitepaper on RBAC/ABAC hybrid best practices and schedule a demo of EmpowerID to manage your permissions.

As George Orwell said, "All animals are equal but some animals are more equal than others."  How does this apply to resetting passwords?  Everyone needs passwords reset, but some need a little extra security around their password resetting.

Let's take the scourge of the help desk, active directory password reset.  Everybody has seen the statistics of how expensive it is to have your help desk take these calls, somehow verify that the user is who they say they are and reset the user's AD password.  On average, $35 per call.

The obvious solution is self service AD password reset.  Give the users an easy link to reset their password when it is either forgotten or they are locked out.  They will answer a pre-configured number of knowledge based questions (eye color, favorite pasta noodle, etc); once answered, the software trusts who they are and lets them reset their password.

The issue with this is that some animals are more equal than others.  Do you really want the CFO's password to be compromised because someone read his facebook profile and figured out his eye color and the astounding amount of fusilli that he eats?

The way to solve this is role based Active Directory password reset.  Based on the user's role in your RBAC system, you will require a higher level of authentication before allowing them to reset their password.  Maybe it's just more questions.  Or it could be two factor authentication via SMS.  Or it could be identity proofing.  Or it could require approval by a help desk employee.  The point is, based on a user's role, you can make this password reset more secure.

I have always found it distressing that the higher level of security needed for a user's role, the more likely they are to be violating some basic security rules.  For example, the CFO has a bit of influence in a company; if he hates changing his password, he can talk people into allowing his account to have a "never change" policy.  Same thing for domain admins.

Role based password management should do just the opposite, it should make these more sensitive roles more secure.  Two factor authentication is not that intrusive, just a quick SMS message that your user plugs into a form during password reset.  Identity proofing is even easier, it again is something the user knows like their monthly mortgage payment.  Security doesn't have to be painful.

And by managing security based on role, you don't have to assign this stricter level of authentication if all that role does is punch in and out of the timeclock application.  You still save that $35 per call but can also protect your network with more dexterity.

And here's the best part.  This isn't limited to Active Directory.  If you are managing all of your passwords through EmpowerID, you can reset all of your passwords together or separately.  You can reset your salesforce.com password separate from AD.  And you can do all of this based on your user's role.

EmpowerID password manager utilizes roles and resets passwords, one of the benefits of having a purpose-built integrated IAM platform.  Schedule a demo and see how you can keep your CFO's account more secure.