All-In-One Identity Management and Cloud Security

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!

The bane of every SharePoint project is permissions and rights.  Access is controlled via SharePoint groups, these quirky little groups that exist in the SharePoint vacuum and only in the SharePoint vacuum.  SharePoint 2010 introduced the ability to control access via Active Directory groups but gives no way to manage the membership of these groups.  So you end up with site admins managing permissions manually or just letting it die on the vine.

What if you could do true role based access control (RBAC) within SharePoint?  Have dynamic roles for your users that change as the user changes (new department, title, location, etc)?  And then manage site permissions with these roles?  Thanks to SharePoint 2010's claims provider functionality you can.

If you set EmpowerID as the claims provider for SharePoint, it exposes EmpowerID roles in the "People Picker", allowing the site administrator to pick a role (for example, HR managers in the investment banking division) to have access to that site.  These are the same roles that will be used for resource permissions or application access.  And it is possible to see who is a member (if you have permission to view membership of that role) from within SharePoint, making it possible to ensure that the right people have access to the right SharePoint resources.

The thing about roles is that they don't have some of the side effects that Active Directory groups do such as token bloat.  You can be a member of as many EmpowerID roles as you want without impacting your ability to log into the network.  On top of that, EmpowerID offers a polyarchical role structure so you can pick that HR manager role in investment banking from two trees, limiting the number of roles that you need to create.

Having a true SharePoint RBAC system also allows you to manage separation of duties since you can set an SOD rule that says a user cannot simultaneously be in two conflcting roles.  You don't have to worry about accidentally giving an investment banker access to the retail banking SharePoint site.

SharePoint RBAC is just a lot more flexible than managing permissions with groups (either AD or SP).  You get all the benefits of maintaining permissions dynamically without the overhead of managing a completely different set of access infrastructure.  This same claims provider functionality gives you SharePoint single sign on capabilities for your external partners for example without having to have AD accounts for them.

I have often said that to see EmpowerID is to love EmpowerID.  The reason is that when clients are looking for Identity & Access Management (IAM) solutions they fall in love with the idea of a complete IAM platform, one built from scratch on a single codebase that allows for seamless integration of user provisioning and management, access governance, federation, and audit intelligence.

Having these pieces together and interoperable gives the ability to integrate workflows that marry authentication and authorization in one place.  When provisioning a user account, you can create application accounts based on their role.  You can force a second level authentication if a certain role is accessing a certain application.  Separation of duties can be applied across multiple applications.

These actions aren't possible if your SSO solution is distinct from your provisioning solution which is different from your RBAC solution which is different from your audit solution.  Even when purchased from a single vendor, these are often "frankenproducts" built from various acquisitions and mergers.  If you don't have a single platform, you might as well have five or more.

EmpowerID puts all of these IAM capabilities in one platform.  That is what allows you to check the user's role when authenticating; to create a workflow that does identity proofing when accessing secure resources; to offer attestation for group and role membership or application access.  In short, to make identity management unobtrusive for a better user experience.

We had a call today with a gentleman who needed to provide access to twelve different web applications.  His choice with other vendors was to have federated SSO with the applications or have an RBAC solution.  With EmpowerID, he realized that he'd be able to have the two married AND add the user provisioning to all 12 applications based on the role of the user.  A complete platform for his IAM needs.

Schedule a demo, take a tour, and fall in love with a complete IAM solution.

Identity information is stored in directories; so it would stand to reason that directory synchronization is the key to identity and access management (IAM).  But that igores the Access in IAM.  Shuttling identity attributes between directories, databases and applications helps but isn't full Identity and Access Management.

Of course, directory synchronization is a great place to start.  You want your access to be granted dynamically based on who and what your user is.  An HR manager in Topeka needs a different set of access than a sales director on the Skynet account.  In fact, those two users need to be synchronized to a completely different set of directories; this is handled with role based provisioning, where only that particular role gets a user account and access in that directory/application.

EmpowerID puts a metadirectory in the middle of your identity ecosystem that will create "person accounts".  Each "person" will have joined user accounts in every system, database or directory.  If they are supposed to have an account in any application based on their role, they will be provisioned.  Once provisioned, attribute flow rules are defined to make either side authoritative or last change wins.  Constant inventorying of directories keeps them synchronized.

All of this constant change is sort of the engine for the rest of IAM.  Your directory changes are reflections of your user changes.  The person directory knows that you got promoted, knows that you changed phone numbers or have a new account.  This drives your dynamic role assignments that provision new user accounts, give an elevated level of access in salesforce.com or grant you admin rights in SharePoint.

The directory synchronization drives your identity...your rights, your permissions, your accounts.  You have to have this capability but you cannot let this capability be your only method of managing identities.

In the past, I have seen some of the largest organizations in the world get overwhelmed just keeping their directories accurate.  This back and forth and constant change (up to 20% internal turnover on top of 5% external turnover) takes too much time to have a chance of keeping on top of the finer more intricate IAM tasks.

But it doesn't have to be that hard.  Take a look at that graphic above, it's that simple.  Rules can be inserted to transform or edit values (one directory has first and last in one attribute, while AD has it separate for example).  Getting the correct attributes flowing throughout the organization is the fastest and simplest part of EmpowerID.

Once you are there, a corporate metadirectory becomes immensely valuable in identity management.