All-In-One Identity Management and Cloud Security

Security is not easy.  IT's goal is to find a way to increase security without adding complexity to the point where it reduces productivity.  It is a fine line and one that needs constant balancing.

Authentication is a key point on this security balance beam.  Password complexity, multi factor authentication, adaptive authentication, federation and single sign on are all considerations in how to deliver security without hindering productivity. 

Starting on one end of the spectrum (no security but easy for users) is a simple eight character password synchronized to all of your applications....that is not good.  On the other end of the spectrum you can have each application having a separate complex 16 character password with biometrics and identity proofing and an OATH token....your users will kill you.

I believe that targeted two factor authentication with single sign on is the answer.  Adaptive authentication is what makes this work.  Because EmpowerID is built on a visual business process oriented workflow platform, you can insert additional authentication options into any workflow based on either the role of the user authenticating or based on the application that the user is tying to access.

Examples of these two options are:

• Adaptive authentication based on the user's role: All users should be able to authenticate into the network with a password but more highly privileged users (domain admins or VPs of finance) should have a higher level of security.  These users will be placed into a role or group that requires a second authentication factor such as an OATH token.  (note: I find it very interesting that those with the highest level of access tend to be those who can control their authentication level such as CxOs or domain admins)
• Adaptive authentication based on application:  This option will result in much less resistance and one could argue is actually more secure.  When a user tries to access a more highly sensitive application or resource, the EmpowerID workflow will recognize the resource as security level X and apply a more stringent authentication method such as knowledge based questions or an OATH token.

The key to all of this is that the IAM platform must have workflows that can increase authentication levels based on either the user's role or the resource's security level.  EmpowerID's visual workflow can even make a hybrid model of this where certain roles accessing certain resources can trigger the advanced authentication.

It is also crucial to use the correct second factor.  As you know, the first factor is what you know and the second factor is what you have and the third factor is what you are.  Remember that balancing act between security and productivity?  The productivity side also incorporates how hard it is to get the second factor into your users' hands.

How hard is it to get iris scans or fingerprints for every user?  How hard is it to deploy smart cards for remote users when you have a 5% turnover per year?  How difficult is it to manage physical assets to manage the "what your users have" factor?

This is what makes smart phones so darned valuable.  Everyone has one.  The flip side to the BYOD revolution is the first three letters: users bring their own!  You can take advantage of this by having users register their devices as part of the authentication (yes, EmpowerID can do that for you).  Then either text a code or demand an OATH token as the second factor.

There are plenty of open source apps available (for example, this one for the iPhone) for the OATH client so you don't even have to deploy hardware.  EmpowerID has its own OATH server, creating a simple seamless way to incorporate an open standard such as OATH and the widely available smart phone from your users to create a very flexible adaptive authentication method using two factor authentication.

And you get to balance productivity and security by selectively applying this second factor to highly secure and confidential resources and highly privileged users.  Additional security without sacrificing productivity.  Schedule a demonstration of EmpowerID and see how we can make that a reality for you.

Identity and access management (IAM) is a big concept.  Google analytics tells me that there are 18,100 searches for this term each and every month.  Gartner's definition is that "IAM ensures the right people have the right access to the right resources at the right time, enabling the right business outcomes."  That is a big concept.

However, it is rare that an organization is trying to solve every single aspect of IAM in a single project.  Some do and EmpowerID can do it.  But most don't and they need a modular approach to solving the IAM problem. 

To break down Gartner's definition:

• The right people: user provisioning into the metadirectory and all applications
• The right access: attribute and role based access control
• The right resources: inventorying of protected resources whether they be applications or files or anything
• The right time: workflow that ensures that all actors (people, roles, resources) are updated at all times
• The right business outcome: a workflow model that corresponds to your actual business process

The best and easiest example is a client who comes to us looking to solve its user provisioning problem (the right people).  EmpowerID does this in its sleep (just kidding, EmpowerID doesn't sleep).  The EmpowerID metadirectory constantly inventories all connected applications and identity stores, updating information and flowing it between any directory or database that needs the information. 

A user is provisioned in HR, gets an EmpowerID person account which then creates application accounts based on the user's role.  As soon as that user is changed in any connected application, that identity information flows througout the identity stores associated with that user.  As their role changes, their permissions change and their access changes.  Once the user leaves the organization, the user is de-provisioned.

As you can see, this quickly leaks beyond the right people to the right access.  And the right resources.  Yet not all products can accomplish this from a single platform, much less one with a single code base.  EmpowerID can.  And we haven't even gotten into what comes next.

User provisioning is a very common use case.  Very common.  What happens next is also common, we ask, "what about single sign on?"  Invariably, the client says something along the lines that they are looking to solve that next fiscal year.  Then we say, "what about your extranet, do you want to manage external identities?"  Just as often the answer is something along the lines of another team has a concurrent project for that.

And this is where having an actual identity management platform comes into play.  EmpowerID can solve the current project's business dilemma and future proof for the additional business problems.  The integrated metadirectory, roles engine and visual workflow platform allow all of the modules to work idependently or in conjunction to solve additional problems.

In the first SSO example, once the users are provisioned and synchronized and you know your identities are accurate, it is simple to base the applications that they can access on the role of these users (remember, you already have that in place).  Just adding a few single sign on workflows opens up the possibility for adaptive authentication based on resource or role.

You can easily incorporate partners and customers into the fold for the second example.  EmpowerID is designed for multi-tenancy so you can even have different customers have different levels of access.  Your roles are in place for your end users so it's easy to give permissions to employees to manage the customer's access and identities.

All of it works together without the need to buy everything at the time of the original project.  One of our more recent customers, a large publishing house, took this exact approach.  Their initial aim was user provisioning and access governance.  Basically, get their own house in order.  The next step is the customer portal, giving end users and book stores role based access to online ordering and account management.  The third phase is getting internal user's access to this customer portal and all of the legacy systems.

Basically, they future proofed their Identity & Access Management on top of their initial project's requirements.  This is an important ability to check when deciding on something as big as your IAM vendor, it's a lot more than just synchronizing some attributes back and forth; it's matching your business processes (now and in the future) to your IAM workflows. 

Schedule a demonstration and see how we can map what you need to what we do and be prepared to think in the future when we ask you what's next.

Believe it or not, we federate every single day in the real world.  The whole concept of federation is that a "service provider" trusts the "identity provider".  In the case of federated single sign on in the enterprise, this means that Salesforce.com (the service provider) trusts Active Directory (the identity provider) and allows you access.

In the real world, the best example is your driver's license.  When you present your driver's license to the bank to prove that you are you, the bank (service provider) is trusting that the DMV (identity provider) has properly vetted you with birth certificates, social security cards, or other identity information.  Because of this trust, or federation, you don't have to carry all of these documents with you everywhere and prove to every single person that you are you.  They trust the DMV (or whatever institution in your country provides driver's licenses) to have taken the appropriate steps to prove your identity.

Don't get me wrong, IT systems are the real world.  And you just need a mechanism to trust your identity provider.  And something akin to a driver's license.  Thankfully, we have several standards that act as a driver's license: SAML, OAuth, OpenID, WS-Trust and WS-Federation. 

When a user authenticates into the service provider (in this case Salesforce.com), Salesforce.com asks for ID.  Since the application is federated with empowerID, the user doesn't have to pull out all of her identity documentation, she just needs the driver's license, in this case a SAML token.  Reaching into her wallet (actually the secure token server in empowerID), she pulls out her SAML token (actually, empowerID sends it to the service provider) and presents it as evidence that she is who she says she is and should have access to the application.

Since Salesforce.com trusts the identity provider and hence the SAML token, the user is authenticated and allowed in to the application.  No username and password (analagous to the mess of identity documents like birth certificates, etc) or difficulties in signing in.

There are other Federated Single Sign On Scenarios (this is scenario number 1, corporate login to cloud application).  But in each one, consider the SAML token (or other protocol) to be the driver's license.  Your user presents this token as identity proof to the bank teller or airline ticket representative or retail clerk and that person (service provider) trusts that you are who you say you are and lets you in.

Once you have this capability, it is easy to trust partners, customers, contractors, and other entities inside or outside of your organization and offer them single signon.  Imagine you are a book publisher who wants to sell books and offer other service options to consumers, authors and editors in an external portal. 

You won't get very far if you are forcing them to re-enter passwords and user names for each application.  Once you authenticate them once against empowerID (your identity provider), they are federated into every single one of those applications.  And the best part is that unlike the real world, they only have to reach into the secure token service once for that SAML token, it moves along with them presenting itself every time they hit a federated application.

Take a look at our whitepaper and see if any of these scenarios apply to you and let's make federated single sign on a real world solution for you.  Click the button below to download your copy of the whitepaper.

To paraphrase Gartner, Identity and Access Management is the act of getting the right people the right access to the right resources at the right time.  Central to that concept is the right people.

Think of the people that you have: employees, contractors, customers, and prospects.  Each of those users needs access to certain resources on your network and you certainly don't want to treat them all the same.  You need role based provisioning to ensure that each user gets provisioned to the appropriate applications.

As an example, your employees will need user accounts in Exchange, SharePoint, CRM, ERP, Google Apps, etc.  Contractors will need a subset of that with more limited roles.  Customers will need accounts in the supply chain software, ticket management, and maybe SharePoint.  Prospect you just want to make sure that they are in CRM and have access to general sites within SharePoint.

So how do you automate this?

For each type of user you will need an authoritative source, the Identity Store of Truth.  For employees and contractors, it most likely will be your HRIS.  For customers, it can be the billing system or CRM.  For prospects, you might want to have a self-registration page.  Each of these Identity Stores of Truth will connect to the empowerID metadirectory, creating a person object that defines roles based on what data store they come from and attributes that we know about them (department, total annual billing, location, etc).  These roles are handled dynamically and change as a user's status changes.

Based on these roles, empowerID will provision user accounts into each of the connected systems listed above.  The metadirectory will then have a joined record of each user's accounts and can synchronize any changes from authoritative sources over to the connected system.

This pertains to the ongoing lifecycle of each of these users.  As you know, users are not static, they change jobs, they move from contractor to employee, prospect to customer and their needs change.  So, provisioning has to keep going to keep up with these users' lifecycles.  This is a key part of the concept of the right person having the right access at the right time.

EmpowerID's metadirectory is constantly inventorying each of these connected systems, if it sees a change to a contractor in the HRIS, it flows that to each application, possibly provisioning or deprovisioning accounts, and most likely changing their roles in all of these systems.

And it is all handled by a visual IAM workflow.  You have probably designed this process on a whiteboard or in Visio.  EmpowerID's workflow emulates this look and feel, allowing you to map the process to your IAM process.  And, the beauty of it?  It is true automated provisioning.  Not just once but every time a change happens.

Once you have your user provisioning automated, empowerID opens up the world of RBAC and federation and password management and governance and auditing.  But start with the "right people" through automated user provisioning and you've won the first and most important battle. 

Schedule a demo now and see how it works!

As reported at ABC News, "early this morning it was found that Skype's password reset tool had been compromised. Discovered by Russian hackers and first reported by the tech site the Next Web, all that was needed to get into a Skype account was a Skype user name and the associated email address. The typical security roadblocks between getting into an account weren't in place; it didn't ask a user to confirm an email address with an email or answer a security question."

Even these steps aren't as secure as they could be.  Self service password reset rides that delicate balance between productivity and security.  Users will forget passwords and get locked out, to minimize the disruption to their work day, you need to offer self service with as few roadblocks as possible.  However, the bad guys can take advantage of this lack of roadblocks and reset passwords. 

You need to know that the person resetting the password is who they say they are.

As far as I can tell in Skype's case, it wasn't really that they didn't have the technology in place, it was that they went too far towards the productivity scale in specific use cases.  Or they had a technical issue, I'm not a reporter, I don't know.

But there is something you can learn from this.  Let's start with the idea of tipping the scale all the way to security while still living in the world or self service (as opposed to making someone show up at the help desk and do an iris scan).

What can you do to ensure that user is who they say they are?

• Knowledge based questions.  This is the concept of "what you know."  The user's eye color, first make of car, favorite pasta, etc.  On its own, this is completely guessable by looking at pictures in the cube or a FaceBook profile.
• Two factor authentication.  This is the concept of "what you have."  When the user attempts to reset their password, send them a text or have them use an OATH token or take a biometric fingerprint scan.  This piece, in addition to "what you know", is the most important step.
• Periodic forced re-enrollment.  If you can force enrollment in the self service password reset program periodically, the user will remember their questions, update with their new cell phone number, and confirm their identity.
• Identity proofing.  There are two ways to do this.  You know a lot about your users (think of all of your identity stores), make them answer something that you know about them that a hacker might not like their date of hire, amount of last commission check, boss's favorite ice cream.  If you don't have that information, you can utilize services such as Equifax' identity proofing where they will answer the amount of their mortgage or some other information.
• Multiple account management.  Active Directory self service password reset is the key one here but if a system like empowerID can manage passwords in multiple accounts and add password complexity on top of your domain policy, then do it.

If you set these steps as your default policy, you will have gone overboard and tipped the scale too far towards security and have a mob of angry pitchfork wielding users on your hands.  So you have to temper it slightly.

If you are using empowerID for this (and I assume you are because I'm pretty sure nobody else can force enrollment like we can!), you also have roles for your users and security levels for your applications.  You can integrate these factors into your self service password reset program by incorporating any of these features on an as-needed basis.

For example, turn off identity proofing and biometrics unless a user is trying to reset their password for a high security system like the financials database.  If the user's role is sales, resetting their salesforce.com account should involve two factor authentication but should not require it for thei quotation system (assuming they need this right now!).

Mix and match security levels of the system and role of the user to determine how far you need to tip the scale.  If you have multiple factor authentication on the most secure systems, you might be able to dial down the requirements just to reset their Active Directory password.

Many of these features are exclusive to empowerID.  For sure, the integration of password management with other identity and access management features is unique to empowerID.  See how to take advantage of these best practices in self service password reset with a personalized demo today.

Adaptive authentication conjures up images of complexity.  Turning over your identities to HAL 9000 or something equally scary.  But, in reality, it can be simpler than that.  Remember the goal of identity and access management per Gartner is to ensure that "the right people get the right access to the right resources at the right time, enabling the right business outcomes."

Part of compliance to that principle is knowing who the right people are and what the right resources are.  So, let's break out the actors in this adaptive authentication scenario into 2 people and 2 resources.  Then it's simple to determine what the right access is.

People (or roles):  1) marketing manager and 2) finance director.

Resources: 1) salesforce.com, 2) folder containing 10K documents, and 3) internal SharePoint portal.

Each user will dynamically belong to a role based on their title, department and location for example.  In this case, we will consider these users as roles.

Both roles need access to Salesforce.com.  It is considered a security level 2 application when being accessed by any role outside of sales and requires a second factor authentication when accessing.

Only the finance director needs access to the 10K documents but since these are highly secure level 3 security resources, not only is a second factor authentication is needed, but a notification needs to be sent to the CFO every time someone accesses the documents.

And both roles need access to SharePoint; no adaptive authentication needed.

This is what makes adaptive authentication possible.  The empowerID directory is actually an identity provider and users authenticate against it.  Since it supports federation, it will use your Windows authentication, but still be managing all of your application and resource access.

So, in the first scenario, when the two users try to access salesforce.com; empowerID will see that their roles are not in sales and force a second factor authentication before authenticating them to salesforce.com.

The same thing happens when each user tries to access the financial documents in the 10K folder.  empowerID stops the marketing manager dead in his tracks since he doesn't have access to that resource.  When the finance director accesses the folder, empowerID enforces the second factor authentication and sends a notification to the CFO.  In this instance, you could also do identity proofing, have a workflow approval, or even grant only temporary access.

The same two users go to SharePoint and both are already authenticated.  Of course, once in SharePoint, the users have different experiences based on their roles in empowerID, but we aren't forcing any extra authentication here.

Adaptive authentication is a fairly straight forward concept that doesn't have to be any more complicated than what we described above.  You set security levels on your resources (as granular as you would like); you create roles for your users.  Certain roles have more stringent authentication requirements for certain security level resources. 

You are able to improve security without forcing these more strict security measures on every single role and resource.

Cloud provisioning and single sign on go hand in hand.  IT wants only the right users to have the right access to cloud applications.  Users want that access and to not be bothered having to re-authenticate (well, actually, they say things like "why should I have to enter another password" in a nasally voice usually).

The problem is that the Identity Management industry evolved from the on-premise world and is stuck in its own tracks.  Most vendors' provisioning solutions were either developed separately from their single sign-on solutions or just don't exist in one platform.  Most of the federated single sign-on vendors don't even have a provisioning solution.

So how do you get that perfect world of a user being provisioned into a cloud application based on their role (or something you know about them), getting the correct application role, and federating to keep the number of passwords down for your users?  And, to top that off, keep your security team happy by de-provisioning that user when their job changes?

You don't do it with cloud vendors or traditional IAM solutions.  EmpowerID's tagline is a "New breed of Identity Management" and this is why.  The platform was built from the ground up without the burdens of acquisitions or partnerships to create the full suite.  So, the whole product line shares the same RBAC model, the same API layer, the same metadirectory, the same visual workflow designer.  It is a true platform.

What that does for you is allow you to have the same workflow for role based provisioning for both the cloud and on premise applications.  Map your business roles to application roles and then apply those roles to role based authentication.  It means that if you provision a user in salesforce.com, you can federate using empowerID as the identity provider, giving the elusive single sign-on for that user.

And, you can get even more granular than that.  If the user is accessing highly secure resources, you can force two factor authentication only when the user tries to access that resource.  Picture this, your finance director logs in to Windows in the morning and checks her email and browses the internet to see what the markets are doing.  She clicks on the link to look at the accounts receivable report, empowerID sees that is considered highly secure, and sends a text code as a second factor authentication; she simply enters that code and is authenticated for all resources of that access level.  When she goes into salesforce.com to see the forecast, empowerID knows who she is and authenticates her automatically.

You have just increased security and ease for your user.

Now for the fun part.  Your finance director is looking at a commission report and realizes that she should be in sales.  She changes departments which is reflected in Peoplesoft.  EmpowerID inventories the HR system, changes her department and roles, which deprovisions her from access to the finance system and provisions her a new account in the cloud based marketing automation system.  She now has an account in the cloud application and single sign on to that app.

We have all been wanting the complete soup to nuts identity and access management system that handles all of this seamlessly.  The world got more complicated with cloud applications but having the new breed of identity management software allows you to provision to cloud applications, offer single sign on, and achieve your IAM goals.

Take 30 minutes for a personalized demonstration of empowerID and see how we can help you achieve all or some of these lofty goals.

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.

In many ways, identity management in enterprises is back where it was in 2001.  We've spent the last decade cleaning up users and roles and provisioning and single sign-on but then the cloud happened.  Half of the access your users need is outside the enterprise in the cloud (I made up that stat, please don't quote it).  And the cloud isn't quite as easy to control.

The first part that is out of control is that individual business units can go out and contract with a cloud application; they don't necessarily need to rely on IT to install it and configure it.  They usually get a web-based management console and take to doing the provisioning & deprovisioning manually despite there being a much smarter way to handle it.

So your first and biggest challenge is just knowing what applications there are.  Finance is usually the only place that can even help you with that.  Then you need to know who should and shouldn't have access to this application.  Basically, what roles in your organization should have what role in that application.

Then you have to speak to that application.  Thankfully, most cloud applications have APIs but you have to learn all of their APIs and find a way to code the basics of provision, deprovision and roles.  You need to find a way to manage changes in roles and make sure that you aren't paying for users that aren't using the application any more.

And, lastly, the age old password issue.  The most insane downside to the business setting up their own cloud apps is that they will still blame IT for them having to remember another password.

All of the above sounds familiar.  It is exactly the same discussion that was had around whiteboards at the turn of the century, just with the added cloudy complication that IT doesn't control all of the applications.

Rest assured though, some identity and access management vendors have kept up.  EmpowerID's metadirectory connects to cloud or on-premise applications equally.  Managing user provisioning, authentication and role based access control are as simple as mapping our workflow shapes to cloud application APIs. 

Your provisioning and deprovisioning can be handled based on your role within the organization.  Only sales gets an account in Salesforce, marketing to Hubspot, support to Zendesk, everyobody to Office 365.  By managing roles dynamically, if someone moves from sales to marketing, you can deprovision the Salesforce account, improving security and your monthly bill.

And each of these applications has roles within it so not all Sales department roles get the same level of access in Salesforce.  An account executive has a certain level of access, while a sales director has a more robust role.  By incorporating a simple drag and drop visual role mapping capability, EmpowerID allows you to manage application roles in the same way you manage your corporate roles.

But connectors and APIs don't help with the password problem.  Thankfully, SAML, OAuth, OpenID, WS-Trust and WS-Federation do.  Most cloud applications are SAML-enabled, meaning that you can federate with the cloud applications and offer a single sign on experience.  Users authenticate into your network, click on a link to their cloud application, empowerID's secure token service sends a SAML claim over to the federated application and, boom, single sign on!

EmpowerID's claim to fame in this equation is that it is one single platform handling the provisioning, deprovisioning, RBAC, and federated single sign on.  They can be decoupled, but having a single purpose-built platform handling all of the heavy lifting for on premise and cloud identity management is much more 2013 than 2001.

We learned a lot of lessons in Identity and Access Management (IAM) over the last decade, let's not let the cloud make us forget them.  I've included a few links to whitepapers below, please click on them to see how empowerID embraces the best practices of IAM in the cloud.  And, most importantly, schedule a demo to see how it might fit into your environment.

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.