All-In-One Identity Management and Cloud Security

Sometimes there is no authoritative source.  Sometimes you just have to say, "Bob, provision me a user."  These are the cases where you will need a very flexible user interface to control user provisioning workflows.

See, that's the cool part, the UI is just what initiates the workflows in EmpowerID, the exact same workflows that are used when it detects a new employee in the HR system.  The same series of events are kicked off: assignment of roles, membership in groups, new accounts in the cloud, notification to the party planning committee, a single sign on dashboard.  It's all there, you are just starting it differently.

Of course, authoritative sources are called that because they have authority.  You can trust them.  With delegated user provisioning, you need to have some additional controls.  The simplest and most efficient is to have an approval workflow shape where somebody in authority has to approve the new user.  Or approve any role with a security level over XYZ.  These approvals can be serial or parallel, they can go to someone in IT or HR or anywhere in between.  They can be decided based on who the new user is.  The important part is that one rogue employee won't be creating any domain admins named Joe Derp.

Another consideration is the complexity of the user interface.  EmpowerID ships with over 400 usable out of the box identity management workflow templates.  About ten of these include user provisioning forms, ranging from what we call "super simple user provisioning" to "user provisioning". 

The difference is what fields are required.  In super simple, the user puts in the name, department, title, and location of the user and EmpowerID dynamically assigns roles.  In simple, there is a dropdown of available roles depending on the attributes already defined and who the requester is (help desk can create X roles and HR can create Y roles for example).  There is also an IT based form where a sys admin who understands things like OU structures and the such can granularly define any attribute.

Just my own personal opinion is that delegated user provisioning should always have an initial lifecycle.  This is easily accomplished by adding an expiration date dropdown on the form or creating a business rule in the workflow that it needs to be certified and renewed within that date period to continue its existence.  This is basically adding attestation to any user provisioning that happens outside of automated processes.

The reason I believe this attestation and lifecycle are important is the use cases for delegated user provisioning.  The most obvious ones are:

• temporary employees or contractors
• task based highly privileged accounts
• additional accounts for an existing user
• partners and suppliers accounts

None of these types of accounts should be subject to having perpetual access and permissions within your network.  With a strong IAM platform like EmpowerID, these security concerns can be alleviated even on users provisioned outside of normal channels.

Take a look at this video demonstrating EmpowerID's role-based user provisioning; you can see some examples of the delegated user provisioning forms (because showing automated user provisioning makes for a boring demo :) ).  Then schedule a personalized demonstration where we can help you start designing your own user provisioning processes.

EmpowerID believes in the philosophy that teaching a man to fish will keep him fed for a lifetime.  The same thing applies with identity management, it should not be a software that you need to keep hiring consultants every time you want to make a change to your business processes.

EmpowerID is the best value in IAM with the least complexity.  The key is our all in one platform approach covering everything from SSO with Web Access Management, Provisioning and Identity administration, Governance, a Virtual Directory, multi-factor authentication, and a visual workflow platform all on a single code-base that was not acquired piece meal and stitched together.  EmpowerID delivers more value day one with over 400 usable IAM workflows out of the box.

This is evident in our Identity Managment training program.  We offer both administrative and and developer training to teach you to fish and have an immediate impact on delivering IAM functionality out of the box day one.

We provide an extensive Wiki that covers all of our documentaiton and is publicly available.  This wiki gives extensive instructions into the how and why of all of EmpowerID's identity management functionality.  Our customer forums give a place for customers to compare and contrast ideas and solutions while having a direct link not only to support staff but developers, architects and engineers as well.

We have recently published overviews of the training to give a head start to customers wanting to see how the product works and is configured, along with identity management best practices.  They are on our YouTube channel here:

• Intro to EmpowerID
• Critical Concepts
• RBAC Concepts
• RBAC Delegation Architecture
• Designing a role and location infrastructure
• Role and location design scenario
• Using the web interface
• Using the management console
• EmpowerID server architecture
• Preparing a server for EmpowerID
• Performing a basic EmpowerID installation
• Adding a server to EmpowerID

One of our implementation engineers told me on my first day that he could have EmpowerID up and running and managing Active Directory automatically within two hours in an organization.  Adding additional identity components are just as efficient.

Take a look at our identity management training and ask yourself, is my solution that straight forward?  Are my processes that good?  Do I know how to fish for identity management?

How about a trick question?  What is your most authoritative source for identity information?  It's not that tricky....your HRIS.  But your actual users are an awfully close second.  They know themselves and if you give them a self service portal, they can make your life easier.

The real trick is what you allow them to update via self service.  Most shops allow some limited Active Directory self service.  But there is so much more that you can open up with a well designed self service identity management system...as long as you put controls, approvals and lifecycle into effect.

EmpowerID's HTML5 interface gives users a clean view into any application or identity store via a single interface from any device.  Attributes, group and role memberships, and permissions for any identity store / application can be managed via the metadirectory with updates either pushed directly to the application or synchronized on a scheduled basis.

Any field can be hidden, read-only, or editable based on the user's role(s).  Approval workflows are managed via EmpowerID's unique RBAR architecture (Rights Based Approval Routing), allowing you to easily manage who can and cannot make and approve changes.  Lifecycle can be applied to any object or membership, allowing you to have full identity lifecycle and temporary privileged access.

But the most important factor is what your users have access to self-serve.  Where most solutions stop at Active Directory, EmpowerID just starts there.  If a user needs to change their home phone number, that information needs to filter to AD for the GAL, HR for contact information, the emergency notification system, and to benefits databases.  Important information like this should not be left to scripts written by some contractor who won't work there in 3 months.

There are other glaring examples around group memberships which affect other systems.  Dynamic group memberships that are driven off of identity information.  Office locations that determine parking privileges.  Mobile phone numbers for second factor authentication and device registration.

Think of all of the things your users know about themselves that you cannot find out.  That is your list of attributes and systems that you allow self service for.  Think of everyplace that those attributes need to be synchronized.  That is your list of applications, databases and directories that you need to connect to.  Think of everyone who can actually approve those changes, that is your RBAR structure.

Allowing self service for identity management does not replace the connectors, synchronization and metadirectory.  It complements it and makes a more thorough identity management solution.

Every beginning has its end.  What goes up most go down.  The circle of life.

Lifecycle exists everywhere, but very specifically in identity management.  The "phrase du jour" appears to be Identity Governance and Administration but at one point it was Identity Lifecycle Management...lifecycle is the governance and administration part of the new phrase.

Going through customer requirements every day, I noticed that lifecycle is sometimes forgotten due to these new phrases.  But the biggest security threat you have is the users who have access that are no longer with your firm.   Or have a new less secure job within the firm.  Or were a contractor that is now working with your competitor.

Two objects within your identity store need lifecycle most desperately: users and groups/roles.  If you manage those, the permissions will follow.  These two objects need several actions: start/stop dates and attestation / certification.  Basically set the parameters of the lifecycle and give a mechanism to approve that identity lifecycle and allow exceptions.

Let's start with user lifecycle.  You have several types of users: internal & external, person & application, permanent & temporary.

• Internal/external users: these should be in a metadirectory that allows you to manage them separately and not equally.  Internal users should have their lifecycle determined by an HR system, you really don't need to set an expiration date unless they are temps/contractors.  External users should have a set policy on how long they live with an internal user attesting to their account on a scheduled basis.
• Person v. application users: The person object is an EmpowerID terminlogy to note the user's identity, linking each application user account (AD, SalesForce, Google Apps for example) to the person object.  Application accounts should either have a lifecycle that needs attestation and certification or be tied to a role or group membership (which likewise has a lifecycle).
• Permanent v. temporary users:  Temporary users come with a builtin lifecycle, you know that you are only authorized to hire a contractor for a 3 month engagement, it is easy to tie an expiration date to that user but you need to have an attestation workflow that easily extends the user without having to re-grant all of their privileges.

For role and group lifecycle, you need to manage three things: the lifecycle of the role/group itself, the membership of that role/group, and the permissions that the role/group has.  EmpowerID delivers stock workflow templates for all of these lifecycle actions. 

• The lifecycle of the role/group itself: This is similar to a user lifecycle in that the business owner of the role and/or group needs to attest to its usefulness to the business every x months.  The ability to determine different lifecycles for each role/group is essential as well as have some never expire roles (domain admins for example).
• The membership of that role/group:  The membership certification of a group is a regulatory requirement in many industries but one that is often overlooked.  The business owner should have a way to either certify the rule that populates the group (clinicians in Ohio for example) or the exact membership.  Any membership exception needs to be noted and certified as well.
• The permissions that the role/group has: Once you know the group should exist and the membership is correct, the owner of the resource should attest to which groups and/or roles have access.  They don't need to worry about whether the membership is correct, the proper business owner already did that, they just need to say "yes, my patient records should be accessed by Ohio clinicians".

These identity lifecycle workflows can be incorporated into your provisioning, audit and governance workflows without much more effort.  You will have better regulatory compliance, your business will be more secure, and your users will be the right users having the right access to the right resources.  Schedule a demo of how identity lifecycle management should work now.

An OATH token is a secure one time password that can be used for two factor authentication.  The first factor is something you know (a password, mother's maiden name, the whereabouts of Jimmy Hoffa) while the second factor is something you have (a smartphone, email address, etc.).  The OATH token is sent to something you have as a one time password to increase security in authentication.

The OATH encryption algorithm is an open source standard and, as such, is widely available.  EmpowerID ships with an OATH server to encrypt the OATH token while clients such as Google Authenticator are free and widely available for smart phones and tablets.

When the OATH server is combined with a sophisticated Identity & Access Management platform like EmpowerID, it opens up a wide range of uses for multi factor authentication.  You don't have to broadly apply the increased level of authentication across all use cases; rather, you can choose the resources or users/roles that require enhanced security and apply two factor authentication strategically.

Since EmpowerID ships with multi-factor authentication as part of the base platform, we see a lot of use cases on how organizations apply OATH tokens.

Self service password reset - When users are locked out or forget their passwords, you need an additional means of verifying their identity.  The traditional method is a series of knowledge based questions (mother's maiden name, eye color, etc).  However, since most of this information can be gleaned from social media profiles, an OATH token as a second factor is almost mandatory to determine the user's identity.

Step up authentication - Once your users are already authenticated, you may want to increase the level of security based on what they are accessing.  An example of this is when your user is attempting to access the financial reports for the 10K report.  They have already entered their username and password, but you want to have that second factor for both security and auditing reasons when they access a resource with a higher security level.

Single sign on to cloud applications - This use case is similar to the previous step up authentication, but is more broadly applied.  If you are offering single sign on (SSO) to internal applications, you might want to step up the authentication before leaving the network to access cloud applications.  This extra level of authentication coupled with Federation or Web Access Management keeps your SaaS applications doubly secure and your CISO happy with precautions you are taking with the cloud.

Admin or executive accounts -I have always found it interesting that the users with the highest privileges tend to get away with the lowest security  --  admins because they control security and CxOs because they sign the admins' checks.  These are exactly the users who should have multi factor authentication and OATH tokens are a fairly innocuous way to deliver that security.  Plus, it gives them a chance to look at their phones in meetings!

After x number of incorrect authentication attempts - This use case requires a fairly powerful workflow based IAM platform like EmpowerID that can re-route the authentication requirements based on calculations or an algorithm.  This can be applied to any of the use cases above but is especially useful to prevent hacking attempts.

OATH tokens as second factor authentication are incredibly useful but it's more than just spinning up an OATH server.  It needs to be integrated in with your IAM platform to be able to strategically and surgically apply its extra level of security and protection.  If you roll it out en masse, you will have a user revolt.  If you apply it in a way that makes sense to the users without an undue burden on them, you win and security wins.

EmpowerID's extensive and customizable visual Identity Management workflows have multiple second factor authentication shapes out of the box, allowing you to simply select a template, configure it for the use case you need and get the most out of OATH and two factor authentication.

In a perfect world, all of your applications would run on one OS, built by one vendor and speak to each other seamlessly.  Every user of every application would have the correct level of access and sign on easily with a single set of secure credentials.  Of course, this perfect world doesn't exist and will never exist.

So, for identity management in a complex world of multiple OS's, vendors and programming languages, you need to go with the hub and spoke model of a metadirectory.  The metadirectory inventories all of the various identity stores, detects changes and based on your rules, provisions new accounts, updates attributes and changes roles and permissions.  With a well-designed metadirectory and capable connectors, you can have multiple "sources of truth" and manage identities in any system or application.

It's those connectors that can get tricky.  Cloud applications all use their proprietary APIs (hey SaaS vendors, think about SCIM), LDAP isn't even always LDAP, and then you get into craziness like BAPI for SAP.  You probably have legacy applications on AS/400, Mainframes, Windows, and various versions of *NIX.  There just isn't a one size fits all perfect world connector.

Because of this, EmpowerID employs a connector framework that allows connectors to be built more easily for those that we don't have out of the box.  The most common connectors (Active Directory, Google Apps, SalesForce, UltiPro, etc) are available off the shelf.  For the rest, the connector frameworks allows us to match our IAM workflow actions to either APIs or web services or AIF or XML.  The framework makes it incredibly flexible.

EmpowerID also can communicate to all of the legacy platforms such as AS/400 or Mainframes or the various flavors of UNIX and LINUX.  We partner with Identity Forge to present all of these systems to EmpowerID in a consistent format for our connectors to communicate.  This lessens the deployment time and effort to get to that perfect world of communicating identity information to all platforms.

A well designed metadirectory does a lot to bring you to that perfect world.  If it is the basis of an integrated IAM platform like EmpowerID, you can easily CReate/Update/Delete user accounts in any application on any platform.  Well thought out connectors allow you to project roles into those applications.  Proper application of SSO (whether it be federated or Web Access Management) and two factor authentication gets your users authenticated to the applications from any device.

None of us have the luxury of a perfect world with an entire IT infrastructure built on greenfield.  What you can have is an IAM platform that communicates like it's the perfect world.

We see a lot of Identity & Access Management (IAM) projects at EmpowerID with a wide variety of use cases and needs.  Our IAM platform is the most fully featured and cohesive product on the market, offering a wide variety of identity solutions from Single Sign-on to Role Based Access Control (RBAC) to User Administration and Provisioning to Identity Governance.  But that isn't the only reason we have over 400 IAM customers.

Where we always do better than our competition is our IAM implementation plan.  We believe in putting the full solution and plan and cost and SOW up front to help make the decision easier for our clients.  Other vendors don't always do that; if you found this blog post by searching for IAM implementation plan then you might already realize that.  Here are the items to consider when looking for an implementation plan from your IAM vendor.

The IAM implementation plan is usually delivered in the form of a Statement of Work (SOW).  You should expect that the implementation costs should be in the neighborhood of 25-50% of license costs, with a lower percentage as those license costs increase.  Of course, incredibly complex requirements may make that number higher, more standard functionality should make it lower.  Having more out of the box functionality (such as workflow templates) can make complex functionality standard in some products like EmpowerID.

Consider these factors when evaluating your IAM implementation plan.  It should include:

• Interactive discovery session
• Clear achievable objectives
• Product capable of achieving objectives
• Team members outlined in plan
• Milestones
• Costs in writing upfront
• Change management plan
• Administrative training

Interactive discovery session

Your plan should include a detailed and interactive discovery session to map your business objectives to your IAM workflows.  A good portion of this discovery should happen prior to the SOW but there should be time alloted to digging deeply and truly understanding your business objectives.

Clear achievable objectives

The objectives should be clearly laid out, understandable and related to your business.  Provisioning users to a SQL based application is not an objective; provisioning a user and delivering login credentials to your XYZ app within 1 hour of hire is an objective.

Product capable of achieving objectives

EmpowerID is able to offer these successful IAM implementation plans because the platform was built on a foundation of visual workflows that do IAM work.  EmpowerID ships with over 400 out of the box workflow templates that can be customized and configured much faster than competing solutions.  Make sure your plan includes how the product is going to achieve these objectives (hint: an excessive amount of coding is a red flag).

Who is going to be doing this implementation?  Consultants?  An outsourced offshore organization?  Internal employees who can come to your site?  Know who will be doing the work, ensure that they are involved from that first discovery session to that final training session.

Milestones

You don't want to find out that your IAM implementation plan is off track a week before you are supposed to go live.  Have concrete milestones in your plan.

Costs in writing upfront

More than a few clients have made a decision on which product while comparing apples to oranges.  Know how much the implementation will be before picking your product; you should choose on the total cost of ownership.  If your vendor won't or can't tell you how much implementation services will cost, think long and hard about what that means.

Change management plan

You will not want the same thing a year from now that you do today.  Ensure that there is adequate understanding of change orders and what that means before starting the project.

Administrative training

Training is closely related to that change management process.  IAM products are complex enterprise software, very few IT Pros just figure it out.  Ensure that there is the appropriate level of administrative training so that you can manage the changes and the configuration as your needs evolve.  EmpowerID's philosophy is to teach a man to fish instead of giving him fish, training empowers you to manage your own Identity and Access Management.  You also need to know it's a product that you can manage yourself.

In summary, get this plan before choosing your IAM platform.  The IAM implementation plan is an essential component of the offering.  Your product needs to be able to address your identity challenges but it also needs to be able to be deployed in time to solve those challenges to help your business.

EmpowerID is able to offer everything outlined in this blog post because it is a full IAM platform that is built on a single cohesive single codebase, all of it developed in house.  Those 400+ out of the box workflow templates get you started fast and with an achievable IAM implementation plan in place from the start.

Remember your first day on the job at your company, you were given access to a few things, keys to the kingdom if you will.  A year later you were promoted, given new responsibilities and a few more of these "keys".  By the time you've been at a company for a few years, your "keychain" looks like one of those giant keyrings that a NY super has.

This illustrates why everything in Identity Management needs to have a lifecycle, a beginning and an end.  Obviously, a user has a lifecycle: hire date and fire date.  Their roles need a lifecycle based on what gives them that role (department, title, location).  Similarly, group memberships and existence need a lifecycle. 

Access to a resource needs a lifecycle.  Not just membership in the group or the group's existence, but the access of that role or group to a resource (file share, application, et cetera).  When you provision a user in an application like Google Apps, you want to periodically ensure that the user should still have that account.

Everything needs a lifecycle.

So, how do you manage that?  There are two primary methods, attestation and dynamic assignment.  And, just to invoke Inception, sometimes you may need to attest to the rules of dynamic assignment!

Let's start with attestation.  This is not only a good business practice, but required for all sorts of regulatory and compliance reasons.  The owner of an object or resource needs to periodically attest or certify that that resource should still exist; this could simply be responding to an email that yes, this resource should still exist and that the access levels are correct.

In addition to certifying that the object/resouce should still exist, all access needs to have a 360 degree view of its permissions.

User:  The manager of a user or an HR contact should periodically attest that the user still exists.  And attest that the user has the correct group/role memberships and correct application/resource

Role / Group:  This role and/or group has the correct membership.  This role and/or group has access to the correct resources.

Access to Resource:  This resource has the correct roles and/or groups granted access.

Attestation should allow for email responses, have a complete dashboard with that 360 degree view from the perspective of the user/member, role/group, and resource and give a flexible timeline for attestation based on the security level of the access.

A lot of this can be managed dynamically to reduce the number of attestations needed.  If you know that every manager in HR should have access to the 401K administration SharePoint site, just create a dynamic role that queries SAP HCM (or whatever HRIS you use) and places those users in the correct role or group.  You don't need to attest to the membership of the role or group, your user attestation will certify that the titles are correct and you are then guaranteed that the membership is correct.

With a metadirectory like EmpowerID, these attributes can be synchronized through any number of sources and updated every 5 minutes.  They dynamic memberships will be accurate and security will increase.

The same principle can then be applied to application access.  If you are managing roled dynamically, your provisioning and deprovisioning workflows can check role memberships and create/update/delete application accounts based on role based provisioning.  That HR Manager above moves over to Marketing?  Their role changes, the EmpowerID workflow will deprovision their account in SAP HCM and provision a HubSpot account for them!  Dynamically and automatically.

The key to all of this working is a cohesive Identity Management platform that allows you to map business process to identity processes.  Your metadirectory and RBAC engine and workflow platform all work together with a slick HTML5 user interface to give you all of the capabilities to make sure that the right users have the right access to the right resources.

I had an interesting customer call last night discussing using SAP HCM as the source of truth for provisioning users and updating attributes.  He made a great distinction between provisioning users and provisioning identities, especially as it pertains to his current IAM solution which "daisy chains" provisioning and updates.  An update happens in SAP which updates AD which updates app number 1 which updates app number 2 and so on.  This can take forever and often prompts a help desk call before the daisy chain is complete.

This problem is exacerbated due to SAP HCM's e-recruitment capabilities and the need to create accounts and identities for job applicants.  They can't be expected to wait for such a long time to have access to systems that they need for their job application.

This is where the distinction comes between user accounts and identities.  If you go to a hub and spoke model with a metadirectory in the middle, you can create an identity, what EmpowerID calls a "person object".  This identity has a role and can determine which user accounts the identity needs in the appropriate systems.  Role base provisioning creates the user accounts at the same time, reducing the lag between the identity being created and the user accounts being active.

A few benefits from this approach are that you have an identity repository outside of Active Directory for applicants, external users, contractors, etc.  You don't need to create AD accounts and can still give access to important systems, specific to that identity's role and needs.  You also can update user accounts more quickly, applying provisioning and update rules directly to the affected system from the metadirectory without running through a gauntlet of systems to get to the one you want.

The customer in question had an issue with the length of time it takes to affect all of these changes with their current mix of scripts and legacy IAM solutions.  EmpowerID's metadirectory is often set at a default inventorying interval of 5-10 minutes even for the largest organizations due to the unique way in which it polls changes.  This makes the changes happen well before a user can get frustrated and call the help desk.

EmpowerID has a very feature rich SAP connector that can read and write directly to SAP, giving extensive control over this process.  However, this particular customer only wanted to read from SAP and cost is an issue.  EmpowerID gives you options outside of the connector if you can have a flat file dump from SAP, allowing the metadirectory to inventory that file and still affect the changes on whatever schedule is worked out with the SAP dump.

EmpowerID uses its flexible visual workflow platform to make your identity processes match your business process, creating situations like the one described where the customer can achieve their identity goals and reduce costs in IT.  Take a look at the user provisioning video or schedule a personalized demonstration and get your identities AND users provisioned.

Identity & Access Management (IAM) is a big undertaking.  I always joke that the successor to the CIO who purchases a legacy IAM platform is the one that gets all of the credit for the project.  But it doesn't have to be that way; an IAM platform that is easy to install, customize and configure AND that is modular can give ROI along the way.

A partner of ours calls that Think Big, Start Smart.

Take a look at the way EmpowerID segments an IAM project:

Some of these functions can be done standalone, some have a faster ROI than others, some have business owners that can fund the project.  But you have to choose a platform that first off can accomplish all of them and second off doesn't force you to buy all of it if you want to "start smart".

A great example of this is a customer who started by managing users and their access within SharePoint using EmpowerID's built-in claims functionality.  We were able to define a whole slew of dynamic roles and assign those to different SharePoint sites.  Once they had this functionality done, the roles and HR inventorying processes were already defined so a VERY easy next step was role based provisioning into all of the applicable systems.  Once accounts are defined, why not add single sign-on into those applications. 

This project was broken into three phases, all of the platform functionality was installed during the first phase (metadirectory, GRC functions, RBAC engine, visual workflow studio) and the customer just needed to purchase the appropriate module to unlock the functionality for each phase.  They were able to accomplish their main initial goal and future proof for the rest of their IAM needs.

EmpowerID's single code-base platform is what makes this work; we ship with over 400 out of the box workflow templates and all of the capabilities of the metadirectory, RBAC engine, audit/SOD capabilities and visual workflow studio.  This is out of the box regardless of the module.

The sections in green below are the functions that come with the platform:

When you are choosing a platform for IAM, think of these factors.  Can you start smart, get an initial positive ROI, and future proof for future needs?  IAM is big, never forget to think big.  And that means thinking EmpowerID.  Schedule a demo today!