All-In-One Identity Management and Cloud Security

Role based authentication is not RBAC.  RBAC determines what resource or application you can access based on your role while role based authentication determines how you will need to authenticate to access that resource or application.  In the way EmpowerID performs this function, it is more akin to adaptive authentication.

There is a key difference.  In adaptive authentication, EmpowerID determines your authentication method based on the security level of the resource or application.  For example, to access the main intranet page, you only need to authenticate with your username and password.  To access the employee benefits portal, you may need to authenticate with username and password but also add identity proofing (answer something only you will know).  To access the financials, you will need to perform multi-factor authentication such as enter a PIN that EmpowerID sends to a mobile device that you have registered.  Again, adaptive authentication is all about the security level of the resource or application you are accessing.

Role based authentication is all about you.  Who you are and what your role is determines the levels of authentication you will need to perform.  Back to examples, every employee role needs to enter username and password when authenticating.  Privileged roles such as domain admin or CFO might need to add additional authentication methods such as identity proofing or multi-factor authentication.  Any user who is a member of a role such as "on probation" might need to use multi-factor authentication with a company provided cell phone; using this method, the fastest way to deprovision their access is take away the cell phone, then go and deprovision their user accounts.

But neither of these methods exist in a vacuum.  The best practice would be to manage authorization with a hybrid of role based authentication and adaptive authentication.  Set the security levels on each resource and application and assign roles to each user.  Then develop the authentication workflow where it checks for combinations of role and resource security level to determine what additional levels of authentication are required.  It sounds complicated, but it is pretty simple if you know what resources need the best protection.

I have spent a lot of time lately thinking about passwords and how inherently insecure (unsecure?) they are.  Between users' laziness and apathy towards security and the ease which hackers can break your encryption hashes, a password just isn't enough to secure your most important resources.  Multi factor authentication, whether it is texting a one time PIN or smart cards or tokens, solves this security flaw. 

But at what price to the users?  You will have a rebellion of angry users if you require this extra level of security every time a user logs in.  But with careful implementation of a hybrid role based authentication and adaptive authentication methods, users will only have the extra steps when accessing important sensitive information.  And anyone can understand the need for that.

Let us show you how to accomplish this extra level of security without the onerous burden on your users.

Now you've done it, you have decided to look into an Identity & Access Management (IAM) solution.  There aren't a lot of these IAM solutions out there so it's pretty easy to narrow down the list of IAM vendors.  But, now you have to think, what am I looking for?  What am I trying to solve?

Gartner says that, "IAM ensures the right people get the right access to the right resources at the right time, enabling the right business outcomes."  I trust Gartner so you want to be sure that your IAM solution is doing those things.  Let's break it down:

• The right people: to know the right people you have to have access to all of the identity repositories in your network (HRIS, Active Directory, ERP, line of business apps, etc).  You need to know everything about these users and have a way to "join" the disparate user accounts.  You need to synchronize attributes and provision/deprovision.  You need to constantly inventory all of these systems for any change immediately.  An enterprise directory, or metadirectory, that joins these users and creates what we call a "person object" that links all user accounts gets you to the "right people."
• The right access to the right resources: you could call this identity and access governance or role based access control or even attribute based access control.  We call it all three.  This is the tricky part of all IAM, which is why we built our role engine into everything we do.  Role based provisioning, giving that "right person" the right user accounts.  Hybrid RBAC & ABAC, allowing you to get to an even finer level of granularity by not only looking at the user's role but also looking at attributes to define it further.  Role mapping to ensure that your IAM roles match your application roles (and you only have to manage them in one place).  Polyarchical role structures so that you can mix and match business and system roles for finer granularity.
• At the right time: On average, 20% of your users change jobs every year, that's called internal turnover.  You need to have all of your roles, provisioning jobs, synchronization jobs, and group memberships be dynamic.  This means that they are constantly inventorying every system for changes and kicking off a workflow to make changes to everything to ensure that the "right person" has "the right access to the right resource" right then and there.  It has to be dynamic, all of it has to be dynamic.  Think of it this way, automate automate automate!
• The right business outcomes: this is all about workflow.  Your IAM processes should map into your business, you shouldn't have to map your business process to your IAM solution.  A visual workflow designer that easily (this means without an army of consultants) creates business policy approvals, user approvals, and rights based approval makes all of these IAM changes map to what you need.  Think of it this way, when you are designing your business process, you draw it on a whiteboard.  Shouldn't your IAM process match that and not be lines of code.  Visual IAM workflow.

When you are looking for your IAM solution, this is what you want to look for.  EmpowerID has a pretty amazing solution to all of this and the track record to back it up.  Tell us what you want out of Identity and Access Management and we'll show you how to map it and get all of those bullet points right!

As our friends at XKCD have stated, "Through 20 years of effort, we have successfully trained everyone to use passwords that are hard for humans to remember, but easy for computers to guess."  Password strength has been reduced to p@$$wOrd123.

As a vendor in the password management space, I guess we should be thankful.  We are able to offer self service password reset, password synchronization, federated single sign-on and make a healthy living because of it.  And users are still going to be using p@$$wOrd123 but at least you can mitigate this security risk with a properly designed identity and access management (IAM) system.

Here are the things you can do from an IAM perspective:

1. Two factor authentication(2FA): for high security resources and applications, force 2FA.  Make a user have a cell phone or biometrics in addition to the password.
2. Identity proofing: make the user answer questions that only they would know in addition to the password.
3. Device registration: check to see if they are on a company-owned device before authenticating; if not, send it for approval.
4. One time passwords (OTP): when the user attempts to access an application, send an OTP to a secure email address (note: this doesn't work with authenticating into the network as that is where the email is :) ).

All of these are great solutions but the easiest and most effective fix you can do to ensure the best password strength:  password length.  Make your password policy a minimum of 20 characters and stop forcing upper case and special characters and numbers.  Heck, make it 25 characters or 30.

But, how is a user going to remember that if they can't remember p@$$wOrd123?  Easy, it's a sentence.  It doesn't violate the dictionary rules because it's a lot of words strung together and it's probably a quote the user remembers anyway.  Some to think about:

• franklymydearIdontgiveadamn
• Iknowitiswetandthesunisnotsunnybutwecanhavelotsofgoodfunthatisfunny
• itwasthebestoftimesitwastheworstoftimes
• allinallitisjustanotherbrickinthewall
• pleasenoteihaveneverusedanyofthese

Password length in and of itself doesn't guarantee security.  The best hacking programs can crack any password (especially one with words in it) very quickly.  But if you have a good lockout policy and, even better, two factor authentication, you can keep security very high and allow users to remember their passwords.

Password resets take up a huge amount of your help desk resources, some estimate one third of all calls are password related.  You cannot compromise security to reduce those calls so you have to do something.  I, of course, recommend self service password reset or federated single sign on with EmpowerID but at a minimum, or even in conjunction with, consider a higher level of password strength.

The best password strength is not always the most complicated....wait, that sentence would make a good password.

What makes EmpowerID different?  In the crowded Identity and Access Management (IAM, also referred to as IDM) market, our slogan, “A new breed of identity management“ and a little of our history are helpful in understanding the answer to this question.

By 2005, we had spent three years developing and deploying an easy to use and quick to deploy Self-Service Password Management and User Provisioning product.  We realized that clients were consistently asking for many of the same features that couldn’t be found in one offering:

1. The lower cost and ease of use of an application, but also the power and flexibility of a platform
2. The ability to make Identity Management processes conform to their business practices, instead of making changes to accommodate the limitations of an IAM application
3. A modular approach that allows them to buy just what they need now, with the ability to add support for additional directories, platforms, applications and federated single sign-on (SSO) later
4. Freedom from vendor bias, meaning that they don’t want to sacrifice strong support of Microsoft platforms to get strong support for an Oracle, SAP or IBM platform, or any number of other standard and custom applications
5. A high degree of integration among the moving parts of an Identity and Access Management (IAM) platform and a “single pane of glass” to see security across all connected applications, platforms and directories
6. Powerful Role-Based Access Control (RBAC) that allows them to quickly configure access, views and control by a wide range of hierarchies and locations, but which still can have rights added or subtracted manually
7. A standalone Metadirectory that allows them to store information and extended attributes without stuffing them into an internal system like Active Directory
8. Highly flexible, modern user interfaces with “rights-trimmed” user views and support for corporate theming

The first thing that struck us when we reviewed this list of client requests was that we had to develop a fresh, innovative vision if we were to achieve all of these objectives in one solution.  We concluded that we had to think in terms of a platform, by which we mean a common set of code, logic, services, tools, and interfaces that could span every module that we would want to develop in the foreseeable future.  This platform would also have to offer redundancy, high availability and scalability to meet both the demands of the largest enterprises and the rapidly growing number of organizations that need to securely manage Identity information for their partners and customers.

Cobbling together different applications through licensing agreements or acquisitions would not accomplish a key goal for us that has eluded all other major vendors in the IAM market: producing a full-featured platform that could meet all of a client’s major goals while costing significantly less to develop and to expand, as well as costing our customers less to acquire and to maintain.  Key to this would be to build the entire platform on a single codebase that would allow for the accelerated development of new modules and features.

We realized we had only one option to include all of the items on our clients’ wish list: to start from scratch.  By taking a “greenfield” approach we sought to avoid the architectural and design constraints that limit our competitors and to allow us to offer a breakthrough price point for enterprises that had been excluded from acquiring traditional IAM platforms by their high initial cost and their labor intensive implementation and support requirements. 

Our first task was to decide which key elements would be essential to include in this new platform approach to Identity and Access Management, and these are the core components of EmpowerID that when combined make it truly different:

• Workflow – not just a series of simple approvals that other vendors offer, but rather a comprehensive Business Process Automation (BPA) platform that provides the mechanism for executing every action taken by the IAM platform against other connected directories, applications and platforms.  We ship with over 375 workflows in our complete suite that can be installed and can start performing work in a day.  Our visual workflow designer can modify any workflow and create new ones and allows business managers to collaborate with developers by allowing them to see how IAM information flows and is controlled throughout their enterprise.  It collapses the time for producing client-specific customizations and it creates productivity gains through automation.

• Metadirectory – a robust directory that stands apart from all other connected directories so that it can function as a full authoritative source of the “truth” about any identity and its attributes as provided by direct input to it, or by inventorying or directly querying in real-time any connected source.  This Metadirectory can be used to create and manage the lifecycle of an identity independently of any other directory.  It can exist outside of a corporate firewall to safely manage the increasingly complex world of Federated and Cloud Identity.  The Metadirectory also functions as a directory, enabling organizations to allow external partners and customers to authenticate without creating user accounts in the corporate Active Directory.

• Role-Based Access Control (RBAC) – some applications claim to offer this, but a major platform must extend a robust vision of managing roles.  EmpowerID’s RBAC can determine rights from multiple hierarchies and locations.  It works in conjunction with Attribute Based Access Control (ABAC) and another unique contribution we have made to this technology, Rights Based Approval Routing (RBAR), to create remarkably powerful and efficient security with sophisticated approvals, Separation of Duties (SoD) and Attestation capabilities.
  

• Flexible and modern User Interfaces (UI) – this would seem to be an obvious component, yet it is frequently overlooked by many vendors, despite being the face of the application that all users encounter.  We were determined to lead the industry with highly configurable UI that not only allows the security to control each user’s view, but that also enables client branding to create a rich user experience.  This is an important component in driving user acceptance and adoption of self-service components.

So how have we done?  In the four years since the first release of the EmpowerID platform, we have achieved a global presence in some of the world’s largest organizations and in market segments that include: finance, banks, regulatory agencies, governments, energy producers, healthcare, retail, manufacturers, advertising agencies, manufacturers, primary and secondary education, and software developers, among others.  We have single installations with hundreds of thousands of users managing millions of objects and many projects that connect and provide Identity Management for Cloud applications.

The distinguishing characteristics of our wins include:

• We are highly competitive on the pricing of the EmpowerID suite while  offering lower implementation costs and shortened project timeframes due to our requiring less of the custom development and heavy scripting that characterizes our competitors
• We have replaced many IAM applications or we coexist and interoperate in environments with existing IAM investments because of our ability to incorporate existing code with our open workflow platform and our flexible connector and communications models
• Clients make extensive use of our workflow, using it to automate and to design and automate many non-IAM functions because of the extraordinary capabilities of the platform that allow it to drive efficiencies with secure Business Process Automation.  Some clients have gone as far as to build complete applications on their own using our workflow designer.
• We retain responsibility for a successful completed project – we don’t push our clients to buy EmpowerID independent of delivering a successfully completed project like much of our competition that relies on partners of varying quality to deliver a finished result

We continue to aggressively develop EmpowerID, with the release in March of the 2012 version of EmpowerID in conjunction with two new modules: SSO Manager, which integrates Federated Single Sign-On (SSO) into the platform and File Share Manager, which provides shared folder permissions inventory and management.

EmpowerID allows enterprises to securely manage their identities while generating cost-savings from automating and securely delegating tasks.  Our goal is to continue to make Identity and Access Management easier to implement and easier to maintain, permitting an increasingly broader range of enterprises to own the critical IAM technology they need to realize their automation, compliance and Cloud goals.

Discover the new breed in IAM software by exploring EmpowerID.

SharePoint's People Picker is one of the strangest user interfaces in the world.  A SharePoint site admin generally gives permissions to either SharePoint groups or Active Directory groups.  But if he/she uses AD groups, he/she doesn't know who is a member.

You can solve this conondrum with dynamic Active Directory groups but that still falls short.  Active Directory groups have all sorts of issues with forests and domains and what if the user doesn't exist in AD?  Many SharePoint instances are a combination of access for employees, contractors, partners and customers.  It would be nice to manage the SharePoint permissions for each of those in one central place.

Luckily, SharePoint 2010 supports an external directory as a claims provider.  EmpowerID's metadirectory functions as the claims provider and offers federated single sign on to SharePoint.  And this opens up the world of roles (static or dynamic roles) to SharePoint.  SharePoint permissions management becomes more robust as you can have roles in EmpowerID that reference any identity store, not just AD.

EmpowerID’s powerful hybrid RBAC and ABAC model can be used directly inside SharePoint’s People Picker user interface to grant access to sites, lists, documents, etc. The People Picker allows end-users to search and select any EmpowerID security object such as People, Groups, Roles and dynamic collections just as they would normally search for users or groups.

The EmpowerID RBAC system allows content owners and security administrators to use flexible and dynamically maintained role-based assignments when managing SharePoint permissions. The dynamic nature of these roles can dramatically reduce the administrative burden of manually setting security assignments and automates access granting and revocation based on changes in user’s job status, function or location.

Role based access control (especially when mixed and matched with attribute based access control) gives SharePoint a ton of flexibility in how you assign permissions within SharePoint.  That customer can get the exact access they need (and even SSO) without lifting a finger.  Your SharePoint team can publish internally and know that role based permissions are keeping it safe.

This is all built-in functionality to EmpowerID, let us know if you'd like to see it in action!

Talking to a client the other day about enterprise to cloud access, it became apparent that before considering cloud SSO, cloud provisioning needed to be taken care of.  More than that, role based cloud provisioning.

And this is where it gets tricky in the IAM marketplace.  There are a few companies offering cloud single sign on and doing it well.  They just don't have the platform in place to integrate with the on premise world and do role based provisioning to the cloud as part of that solution. 

And, think about your business goal here for a second.  You want to make sure that the right users have the right access to the right applications.  So, first you need to do role based provisioning; anyone in sales and support needs access to salesforce.  Only those users should be provisioned; after moving to another department they should be deprovisioned.  Data security is one thing to consider but so is license consumption...you pay monthly for these licenses.

Once you've provisioned the correct users to the cloud application (in this case salesforce), you need some role mapping.  That sales rep should have different access than the sales manager than the support rep.  Map your corporate roles to the cloud app role and not only do you get user accounts for the right folks but they get the right access.  As they move jobs, the dynamic role in your enterprise directory maps to the cloud role and presto boomo, accurate access to cloud applications!

And, now for the thing that people worry about.  Cloud single sign on...federating with the cloud application.  This is arguably the least important step but the one that gets the most attention.  Who cares if you only need one password if you have the wrong users getting access?  Luckily, it's possible to do all three and leverage the same directory if you can do SAML federation from the directory that is handling the cloud provisioning and access.

There must be others doing all three aspects of this cloud provisioning, but if any of this rings true to you, schedule a demonstration of EmpowerID and see how to get the right users the right access to the right cloud resources, and SSO them while you're at it!

If you are going to adhere to the principle of least privilege, you also need to consider temporary privileged access.  The idea is that a user and/or administrator should not always have privileged access but will probably need it for a short amount of time.

To do this, you need a few things:

1. a mechanism to request access
2. a workflow to approve the request either by business rules or user approval
3. a mechanism to grant and revoke access in a specified amount of time
4. a mechanism to extend the privileged access
5. a mechanism to audit and report on this access and
6. a "break glass" method of emergency access

In short, you need a robust role based access control (RBAC) system.  If you have all of these pieces you can avoid the inevitable outcome of the off-duty admin saying, "OK, just this once, use my credentials"!  Yes that happens.

Let's think through a use case.  Your internal developers have created a web app that is crashing, they don't have access to production but need to run some tests and troubleshoot what has happened.  They could work with an IT admin and get it done using their credentials but that doesn't always work.

So, they go to their access request portal and request access to the production system.  Based on their role or admin approval, they are either immediately granted membership in a role for 24 horus or a one time password (OTP) that expires after 24 hours.  Either way, steps one through three are achieved.  The developer has access, it's been approved but it's going away in a specified period of time.  They get to work troubleshooting.

One day later, they are still working at it and get a notification that their access is about to expire.  They apply for an extension and it invokes the workflow again.  Maybe this time, the request needs a VP of IT approval regardless of the role the developer is in.  The workflow should be able to handle any business rule you put around the temporary privileged access.  Still, step four done and accounted for.

And "accounted for" is a great segue to the need to report and audit such access.  If this is a sensitive system, or even if you are just a highly regulated industry, somebody needs to say who had access to what, when and who approved it.  Any changes within that system needs to be accounted for and the auditor will need to know how "developer X" got access.  That's step five.

Now, the tricky one, the break glass method.  Go back to the beginning of this scenario, it's Saturday at 2AM and your revenue producing portal crashes.  Nobody can fix it but the developer and your business rules require a VP to approve his access request.  However, that VP is in Fiji enjoying a hard-earned vacation. 

Having a way to circumvent the normal approval process in an emergency is a must.  The workflow takes a different route if this is deemed an emergency request.  Maybe a director can approve it but it will send red flags throughout the auditing community and require a retroactive VP approval to keep them from sending in the infantry.  This gives the emergency access (you still have all of the auditing of who did what and when from step 5), keeps a strong sense of security, gets the project done and keeps you in regulatory compliance.

This need for temporary privileged access (TPA I guess we could call it) happens constantly.  The workarounds are dangerous from a security standpoint if you don't have a mechanism in place.  The effect on your business is probably worse if you just ignore the need.  And you still stand on the high and mighty pedestal of Least Privilege!

A customer was showing us his current state of role based access control for their business intelligence application.  What had happened was that for each segment of BI reporting, he had to create a role.  The real issue was that each of those roles was needed for each region.  So suddenly he had 10 management roles TIMES 4 regions for a grand total of 40 roles that he needed.  Just for his BI app.

He needed an easier way to manage this.  Their solution had been to allow an EMEA user to request North American access and then the approver had to deny it.  It was confusing for both the access requester and the approver.

What helps this is our combination RBAC and ABAC (attribute based access control) hybrid model.  10 business roles are defined and then access requests are security trimmed based on the requester's region (an attribute in the directory).  Attribute based access control allows you to take an actual role and get fine grained for the access request system without the requester even knowing it is happening.

We could even fine tune it further by using rights based approval routing (RBAR).  Let's say they want to define it that anyone in a certain department gets auto-approved, RBAR does that while still requring approval for someone outside of that department even though they are both in the same role!

Remember that the whole goal of Identity Management is to get the right user the right access to the right resources.  What is left unsaid there is "with as little IT interaction as necessary".  You can add some components like ABAC and RBAR on top of RBAC to map these workflows to your business process.

In the end, the customer won't need to create an exorbitant amount of roles, they reduce the back and forth approval process, and make it easier for the end users.  Then for the auditing and intelligence portion of IDM, you'll have a full report and view into whether a person approved the access or a business policy did.  You will be conforming to least privilige principles by security trimming what a user can even request.

Take a look at this whitepaper if you want more information.  If you are ready to start controlling your access with EmpowerID, we'll show you a demo and prepare a trial for you!

One of the  main issues with access requests by your users is they don't know what to ask for!  Think about it, your user knows that they want to see the prior year's sales results sorted by average receivables age.  They go to your access resource catalog and sure enough there isn't a resource named that.

You and I both know what they want is something called sales manager role in QuickBooks but that translation is not apparent to your user.  How do you solve this?  You can't name your role based on what they want to do because other users in that role have other needs.  You can't necessarily have them ask to mimic Bob in the Scranton office's rights because you might have granted him a higher level of permission (never violate least privilege if you can help it).

Until we can intuitively read the user's mind and translate on the fly, we need a way for the user to understand what they're looking to do and assign permissions for that particular task.

We thnk the best way to do that is with access bundles.  This way you don't have to create a bevy of highly specific roles but you can bundle a bunch of access into an access bundle that has multiple related access rights.

And that's where access certification and re-certification comes in.  If you grant this access bundle to a role, user or group, then they all have it until time comes to an end.  This shouldn't be.  Any access request that is granted needs to be attested to often.  The best recommendation is to grant access for 3-5 days initially, if the user still needs it after that they have to request to renew this access.

This request should kick off a workflow to the resource or role owner to certify that the user, role or group still needs access.  At this point, they can grant access permanently, for a set period of time or deny permission.  This certification process can vary by resource or the role of the user requesting. 

View access as a privilege not a right.  But if you are going to keep this principle of least privilege, then make it easy for access requests and certification.  Next time we'll go over the fun part of designing your catalog of access bundles!

If you want to take a look at how this works, we can give you a demo and trial of EmpowerID, just click the beautiful button below!

There are some things that only your users know.  So why not make them the authoritative source for that identity information?  Some examples would be mobile phone number, home phone number, emergency contact information, and oddball information like shoe size.

Providing Active Directory self service gives you a good place to store this data.  Most of these items have attributes in AD and you can easily synchronize that information from AD to your HRIS or emergency notification system.  You can even then start making dynamic Active  Directory groups based on the information.

But you don't want to open ADUC to just anyone so you need a role based Active Directory user interface for self service.  The reason for role based is you need to have security built in to the self service web page so that I don't go and change my colleague's title.  You'll need to have rights based security allowing a manager to change some fields for their employees and the employees to have access to change other fields.

You then want rights based approval routing to make sure that somebody is there to approve any changes that need approval, whether via email or an approvals dashboard.

We have a whole whitepaper on how to replace ADUC, take a look.

But then there's another issue.  What if Active Directory isn't the place to store the information?  For example, you have union employees who need to update their union membership with HR every once in a while.  You don't want that information flowing through AD to get to your HRIS.

We solve that with a metadirectory.  The metadirectory has pretty flexible attribute flow rules so you can create a self service page using our forms designer, have it update the metadirectory (again, using rights based approval routing) which flows directly to HR without AD being in the middle.  To use technical jargon, presto bammo, you have self service updates without IT having to be involved.

This is probably EmpowerID's most basic and simplest use case, with almost the entirety of this functionality able to be installed, configured and deployed in two hours.  Give us a shout for a demonstration and we'll have you up and running in no time, delivering Active Directory self service for user and group management.