All-In-One Identity Management and Cloud Security

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.

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.

Your finance department is watching the cloud.  Not because they are tech literate and following IT trends, but because they can cut your budget quickly with cloud applications.  And it's up to you to help them before they help themselves.

In the on premise world, if a user leaves the company and you keep an application account for a few extra weeks, it only hurts your security.  In the cloud world, you just paid an extra month of service for a user account you didn't need to.  Take a look at your internal and external turnover, pull out a calculator and see if you can make a dent in your budget by managing your cloudy accounts better.

The way I see it, you have two simple options to help you reduce your monthly cloud expenditures:

• timely provisioning & deprovisioning of all user accounts
• role based provisioning to the cloud applications

The first is obvious, if a user leaves the company, you need to deprovision ALL of their accounts, on premise and cloud.  A metadirectory that has inventoried all of their accounts from connected systems (AD, HR, ERP, Salesforce, Gotomeeting, etc) can delete or deactivate those accounts quickly and easily.  This is your external turnover.

But what about internal turnover?  That user who moves from marketing to sales and needs new access to some systems (SharePoint sales site and the line of business quote application for example) and different access to other systems (like Salesforce)?  And they certainly don't need access to applications like their cloud based marketing automation software (Hubsport or Eloqua).

They are going to have a different role in your metadirectory (now sales in Iowa instead of marketing in Ohio) and that can trigger the workflows that will provision new user accounts (in that quote application), change access in some (a different native application role in Salesforce), and deprovision access in their marketing automation application (like HubSpot or Eloqua).

Did you see what just happened by managing application access and provisioning by roles?  We just deleted a cloud based application account (the marketing automation account) and saved the company money.  Every single month.  If you are handling this manually or allowing the line of business (marketing department) to manage it, chances are the company is paying for a lot of cobwebbed accounts in your cloud applications.

Keep finance off your back; take a look at empowerID to manage your role based provisioning for the cloud.

The day after the second password was invented, users started to complain.  "How can I remember all of these?"  Insert some whiney noises here and you have the gist of most helpdesk calls.

IT made some progress with single sign on and password vaulting and all was kind of good.  Until the cloud happened.  What the heck are you supposed to do now?  Each user has dozens of cloud applications they need to get to and you don't really control them.

Thankfully, SAML and federation have happened.  You can federate these external cloud applications with your internal authentication and users can access all of their cloud applications right from the comfort and sanctity of their own desk with just one password.

Your users authenticate into the network once, you present them this fantastic SSO dashboard for all of their federated cloud applications (or on-premise, never forget on-premise) and they are off to the races, being productive and not calling IT.  Keep in mind that each tile above is a URL so they can bookmark them or you can present them on any intranet page you desire.

If your user has another federated application, they go to add application and you present them a new tile.

We call this Scenario 1 in our whitepaper on the Top 5 Federated Single Sign-on Scenarios, Corporate login to cloud application.  Some of the benefits to this approach with EmpowerID are:

• EmpowerID provides connectors and workflows to quickly and cost effectively provision application access in Cloud hosted or SaaS applications as part of the normal onboarding process
• EmpowerID maintains auditing and reporting of Cloud application login history as well as who has access to which Cloud applications
• The EmpowerID Login Workflow provides adaptive authentication security to consistently enforce strong authentication standards such as two-factor authentication and also device registration policies to control access from non-corporate devices
• Users only need to know one password

Chances are that your users are using many SAML enabled applications.  You can easily control their usage, provision and deprovision users, and provide seamless SSO.  This will save you money on your monthly SaaS bills, enhance productivity for the users, and provide security and auditing around the wild west of cloud applications.

Take a look at our whitepaper for more details or schedule a demo and get your users the one password they've been wanting.

Security and auditing are two of the main driving forces in Identity & Access Management (IAM).  Remember the definition of identity management: giving the right people access to the right resources at the right time.  But it's like Schrödinger's cat, both alive and dead until you observe and measure it.

Until you observe and measure your IAM practices and policies, you don't know if the right people have the right access.  And you don't know if the wrong people got the wrong access.  That is where auditing actually helps your business, not just satisfying a regulatory requirement.

Auditing and security is a mix of proactive design and reactive reporting.  You design your workflows in a way that ensures the right people have access, set up alerts for exceptions to these rights, and have a helpful reporting interface for your quarterly or yearly audits.  In our view, if you do the proactive part right, the reactive part becomes a rubber stamp.

We look at a few main categories for your proactive access control design:

• RBAC & ABAC access control
• Native system permissions inventory
• Separation of Duties (SOD) policy
• Attestation and access recertification
• EmpowerID Operations audit log

By allowing a hybrid of role based access control (RBAC) and attribute based access control (ABAC), you can achieve a finer level of granularity around your access without role bloat.  Basically, any time a role needs a finer grain control, you add an attribute check from any connected system and access is only granted if the user is in the right role and has the right attribute.

Native tools are a problem in IAM.  If you can circumvent your identity management platform to change attributes, roles or access, what's the point?  EmpowerIDs will continuously inventory native systems, detect changes and report on changes in the native tool.  It can be configured to alert someone, roll it back or just report on it.

Separation of Duties is an oft-overlooked aspect of IAM.  Basically, there are mutually exclusive roles.  If you are allowed to sign a check, you should not be able to issue a PO.  If you are in the research department in a bank, you should not have access to the retail banking systems.  Again, report on it, set alerts or just plain not allow these conflicting roles or group memberships or access rights.

There are also many cases where users have the right access but should not have this access forever.  Attestation and access re-certification solves this.  You can have resource owners (role owner, group owner, app owner, compliance officer) periodically attest that this access is correct.  Even if this access is managed dynamically, you should still have periodic attestation.

All of these GRC factors are stored in an audit log.  But that doesn't do you any good unless there is a strong vehicle to present these actions and access to the appropriate business owner and/or auditor.  Having an online view, a powerful report generator, and most importantly, a method to take action on any red flags is key.

You want to know who made a change, when it was made, what tool was used, and who approved it.  These changes can be in multiple applications and a centralized metadirectory helps keep it all in one place.

Some of the largest most regulated corporations in the world use EmpowerID to solve these access problems, let us demonstrate how EmpowerID can work in your environment.

Delegate and Automate.  The first two words of IT.  It is especially true with respect to managing Active Directory.  There are a lot of authoritative sources of identity information that Active Directory needs and not one of them is your help desk employees.

And that's one of the main issues with managing AD, it often falls into the help desks' hands.  They get an email from HR saying to create some users.  They get requests to add users to AD security groups.  They might get an email that Jane Doe got promoted to a new job in Operations.  And for all of these changes, they have to have access to Active Directory Users & Computers (ADUC).

Once you have access to ADUC, you have access to ADUC.  By that I mean that the help desk user can not only create a new user but delete an OU.  Not only can they add a member to a security group but they can make themselves a domain admin or member of the executive security group.  It just isn't that safe or secure.

So you want to be able to delegate and automate your Active Directory management.  Have end users have only the access they need to make changes.  Give them a self service portal that follows pretty strong workflow rules, giving field level security to changes on their profile or their users.  Give them the ability to request membership in some groups and not others.  Allow them to manage the membership of a group that they own.

By using rights based approval routing, anything that user is allowed to do is done instantly.  Anything that needs approval from another user is routed for their approval.  Anything that they shouldn't even see (the distribution group of users on steps of discipline for example) never appears before them.

EmpowerID allows this self service management with a level of granularity and security and role based access control that makes ADUC completely irrelevant.  Grant access only to make changes in AD that the user is allowed to.

But that doesn't cover everything.  Automation is your other big step.  Creating a user still shouldn't be done manually.  You probably have an authoritative source like HR that can be inventoried to see if a new employee exists or if an existing employee has changed.  Once the new user is inventoried, EmpowerID will provision the user into Active Directory or make changes to their job title or any other change.

These new or changed users will have a specific dynamic role and will be provisioned into the correct systems, given access to the right resources and be a productive member of the corporation immediately.

With the right combination of delegation and automation, you don't need to have ADUC access for any user.  You can manage all of the AD objects and attributes without the "everything" access that comes with native tools like ADUC.

Take a look at our whitepaper on replacing ADUC and schedule a demonstration of how we can help you delegate and automate.

Not all applications are created equal.  Not all users are created equal.  Different users need access to different applications; different users need different access to these applications.  We call this role based provisioning.  Based on a user's role they get access to the appropriate applications.  Again, based on their role, they get differing level of permissions within those applications.

The interesting part is that you also have on premise and cloud applications to provision.  It's not enough just to create an AD & Exchange account and let the application owners handle the rest.  Not in a true identity management system, one where you are managing roles and permissions centrally and dynamically.

Centrally, you have a role repository and metadirectory.  To correctly provision all of these users to these disparate applications, you need connectors to all your applications.  Building these connectors based on APIs allows you to map any roles and attributes from your central identity store. 

It doesn't matter if this is an on-premise or cloud application, the principle is exactly the same.  Your "person" identity in the metadirectory "joins" all of your accounts.  If your role says that you should have an account in the application, the connector creates the account and then inventories any changes that affect it going forward.

If your user changes jobs, automated provisioning means that their applications and permissions within those applications change.  Moving from Finance to Sales?  Your accounting software application account is deprovisioned and your Salesforce.com account is provisioned.  Role based provisioning lifecycle!  There isn't even an acronym for that it's so cool.

This is what identity and access management is about, giving the right users the right access to the right resources at the right time.  Automated provisioning really is this powerful and possible.  Let us take you on a tour of EmpowerID to show you what it can do.

I am a strong proponent of RBAC -- managing roles effectively does an awful lot more for your enterprise than Active Directory groups.  However, you still need AD groups to be managed.  And, in my opinion, no IT admin should ever have to manage these groups.  What you can't automate then delegate.

Active Directory groups are essential for fileshare permissions, for email communications, a few GPOs, and just plain useful for some application permissions.  You can use them for SharePoint, though I recommend you utilize roles for that as well.  Either way, you still need to manage them without taking up your entire day adding and removing members from AD groups.

To keep from investing a full time person managing AD group membership, you need to do two things: 1) create dynamically maintained groups and 2) offer self service to your users to manage their groups.

Dynamic AD groups are exactly what they sound like.  You write a simple (or complex) query that can read attributes in Active Directory or your HRIS or some database with useful identity information.  Your group memberships dynamically change whenever any of this identity information changes. 

You will need dynamic groups for security groups and distribution groups.  Don't fall for the Exchange QBDL trap...you cannot manage permissions with those.  An application like EmpowerID Group Manager has an exceedingly simple interface to manage these dynamic groups for both security groups and DLs.

The only complication is GIGO, you need to ensure that your identity stores are accurate.  Having a metadirectory constantly inventorying these data stores will ensure accurate information on your users and keep the dynamic AD groups accurate.

Now for the fun part...delegating group management to your users.  Obviously, do not do this without solid workflow controls in place.  You will have group owners managing membership in their groups, this is usually a pretty solid practice.  If you trust them to own the group, you can trust them to manage the group membership.

But the piece you want to add to this equation is group membership attestation.  Either for regulatory or token bloat reasons, make the group owner attest to the membership and existence of this group periodically (bi-yearly for example).  If they don't need it, de-activate the group.  If the member should no longer be in the group, remove them.

There are also groups that your users know they want to join.  Give them a self service portal for joining or leaving groups.  Put workflow on it so that approvals are needed either from rules or approvals.  Make some groups unjoinable (such as the 10K report team) and some wide open (like the book club).  For the rest, have the owner approve membership or allow anyone within a certain division of the company to join it but disallow others.

Which brings us to separation of duties.  Make sure that separation of duties are enforced with AD groups the same way they are with roles.  If your users is on the investment banking side of the house, they should not be able to join any groups in retail banking.  If they are in the invoice approval group, they cannot be in the sign a check group.  These SOD rules have to be built into Active Directory group management the same way they are in your RBAC rules.

It is pretty clear that AD group management is important.  It is also a vital part of your IAM strategy.  If the need is to knock off one piece of ROI-producing identity management quickly, consider group management.  Just think of all of your helpdesk time spent keeping those groups accurate.  Take that money saved and move on to RBAC managing ALL access and permissions!