All-In-One Identity Management and Cloud Security

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.

I might be splitting hairs but access governance and access control are different animals...yet different animals that belong to the same species.  I'm picturing a doberman dachsund mix, cute AND effective as a guard dog!

Most Identity & Access Management (IAM) projects seem to focus on one or the other and often end up with two products, one for access control and one providing access governance.  But why wouldn't you want one solution providing both aspects of access, looking forward and looking backward.

EmpowerID's Role Based Access Control (RBAC) engine secures resources, manages roles and permissions, manages Separation of Duties (SOD), and has a powerfule multi-tier attestation capability.  In addition to RBAC, EmpowerID also incorporates Attribute Based Access Control (ABAC) into its capabilities for finer grained permissions delivered at run-time.  Temporary Privileged Access (TPA) helps keep your organization following the principle of least privilege.

That is access control.  All of these permissions and roles are stored in the EmpowerID metadirectory and projected into other platforms (AD, UNIX) and applications (cloud and on-premise) to give a comprehensive access control platform for the entire enterprise.

And that is the key, it is stored centrally.  All access control for all connected systems and applications.  Sitting there in a comprehensive, scalable, secure metadirectory.  And within that same platform that is controlling all of this access are the access governance workflows.

Access governance comes in two flavors: audit-driven and business-driven.  Auditors usually want reports and stacks of paper detailing all of the SOD violations, the excess permissions, the compliance issues.  Business owners want the same thing but also want the ability to effect the change immediately to remedy an issue.

EmpowerID gives a 360 degree view of permissions to address this (and actually, auditors appreciate this too!):

• Who is a member of a role and/or group
• What resources does that role and/or group have access to
• What users/roles/groups have access to a particular resource

So, you look at it from the user perspective, the role perspective, and the resource perspective.  At any point, with the business-driven access governance approach, the business owner can correct an issue, authorize an exception, or delegate the action.  EmpowerID's approval workflows can escalate anything and all of these actions are then reported for the audit-driven access governance.

The access governance is managed from within the exact same user interface as the access control which give a familiar look and feel and the workflows within a mouse click to fix them.

Access Governance and Access Control do not have to be separate.  Provide the auditor the tools for access governance, but fix the access issues as they happen, not once an auditor finds them.

We have a very large home healthcare client with a very common problem: most of their employees are on the road needing access to corporate and cloud applications using a tablet.  These users have numerous critical applications they need to access for medical history, prescriptions, scheduling and all of the traditional cloud applications.  If they couldn't authenticate and log on, they certainly could not call the helpdesk while sitting with their patients.

The solution to the problem consisted of three parts:

1. Single sign-on using a combination of Federation, Web Access Management (WAM), and password vaulting.
2. Role based access control to give the mobile user the correct access within applications.
3. Two Factor Authentication using OATH tokens for high security applications.

Single Sign-on to these corporate and cloud applications was the first priority.  Because EmpowerID has a metadirectory that inventories and synchronizes identities with all of the applications, we know who the users are.  We configured EmpowerID to authenticate the user and present a unified dashboard regardless of the method used for single sign-on.  Several of the applications were federated using SAML, Web Access Managent (WAM) was used for most, and one lone legacy app was handled with secure password vaulting.

With a mixture of on-premise and cloud applications, this unified interface is essential for the user experience.  EmpowerID's user interface is HTML5 so it configures for the device, giving a modern clean appearance regardless of the screen dimensions (smartphone, tablet, laptop).  Device registration adds another layer of security as IT can keep track of the devices used in the field, even limiting access to corporate issued devices in some divisions.

Of course you need to add RBAC to the mix.  A nurse doesn't have the same access needs as a doctor or technician or delivery manager.  Not only are the SSO dashboards security trimmed based on role(s) but EmpowerID's connectors can project roles into the applications whether they be cloud or on-premise to give the correct access within the application.

These same roles are then used to determine when to demand two factor authentication.  Based on a combination of the user's role and the security level of the application being accessed, EmpowerID will demand a second factor using its OATH server.  Issuing this OATH token gives a layer of security for both the CISO and the auditors.

Accessing today's complex mix of on-premise and cloud applications from a complex mix of mobile and desktop devices is, in a word, complex.  EmpowerID's mix of SSO methods, RBAC workflows and metadirectory simplifies it not only for your users but for IT as well.  Schedule a demo and see how Cloud SSO can be made less complex.

Active Directory is a bear to manage through ADUC.  It is clumsy and all-encompassing and the ability to manage granulary is exceptionally complex.  Delegating and instituting fine grained permissions requires deep and arcane knowledge of Active Directory.  In short, Active Directory management is difficult with ADUC and it doesn't have to be that way.

EmpowerID is a full IAM suite that has the ability to specifically manage Active Directory exactly the way you need, either through delegation or automation.  The actual changes are made in the EmpowerID metadirectory with a very well established and powerful connector to Active Directory.  So, you manage with EmpowerID's RBAC structure and then send those changes to AD.

One benefit of this structure is that you can manage multiple domains and forests from a single instance of EmpowerID.  Your helpdesk in Forest A can manage users in Forest B.  GAL synch is a breeze.

Another advantage is the full auditing controls of EmpowerID.  The ability to institute attestation and lifecycle on any AD object.  Full reporting and audit grids are available for business users and auditors.  Separation of duties can be applied from groups, OUs, roles and managed even cross forest if necessary.

Self service Active Directory management can be rolled out based on the user's roles, giving everybody the exact access to change identity attributes or group memberships that their roles allow.  Approval workflows are easy to configure using EmpowerID's proprietary Rights Based Approval Routing (RBAR).

Dynamic memberships in roles and groups are managed easily and efficiently in EmpowerID.  Group membership is always up to date with the ability to read identity attributes not only from Active Directory but any other identity store.

Everything can have a lifecycle, giving a 360 degree view of attestation and the ability to certify and approve lifecycle attestation from within emails.  Delegation and auditing of attestation should be a given.

Break glass permission workflows are available for temporary privileged access.  So, if an admin needs emergency access to a server, they can run the workflow, be granted temporary access, and have that access completely auditable and reported to the CISO.

If changes are made natively in ADUC, you can have a workflow to roll them back, report on those native changes, or send them for further approval.  Most importantly, with EmpowerID, you can completely shut off native ADUC access.  Many of our customers do this, having all changes made from within EmpowerID.

Active Directory management can be a lot better than ADUC will ever allow.  Read our whitepaper on replacing ADUC and improve your AD management with fewer resources.

The average corporate user has to access over 16 applications in the course of their jobs, that can be up to 16 sets of credentials (username and password).  Assuming 30 seconds of extra time per credential, that's about 40 minutes per week wasted on usernames and passwords.  Factor in a forgotten or locked password per week and you are up to almost an hour spent per week dealing with this wholly un-neccessary routine of passwords.

Why?  Single sign on.  It is better, it's easier, it's more secure.

Your user has to authenticate at least once, usually with their Windows credentials.  Now you know who they are.  You know what applications they have access to, both on premise and cloud.  So why are they having to continually prove their identities to each application?

Of those, 16 web and cloud applications, probably half of them support federation, usually SAML or OAuth.  Note: EmpowerID supports SAML, OAuth, OpenID, WS-Trust, and WS-Federation.  You can federate with those applications, knowing that it trusts that you know who you users are.  Your Identity Provider (EmpowerID) will simply send a token to that application verifying who your user is and the access they have.  No username or password typed.

For those web applications that are not federated, Web Access Management (WAM) is the way to go.  For these applications, EmpowerID either uses an agent in the application or a reverse proxy to secure the URL and pass a secure header variable with your user's credentials.  This tried and true method can usually cover a quarter of applications.

For those remaining applications that cannot federate or use WAM, secure password vaulting can keep the exact same SSO experience for your users.  Your user will claim the account, enter their username and password ONCE, and EmpowerID will encrypt and pass these credentials as your user signs in.

Your users will have a single SSO dashboard for all of these applications and never have to type another set of credentials for any web applications, on premise or the cloud.

That being said, making it too easy can be an issue sometimes as well.  Say one of those web applications stores all of the company secrets, like the Colonel's secret recipe or the location of the exhaust vent on the Death Star.  You have to secure that, right? 

That's when you add a second factor authentication to that specific application.  Incorporate an OATH token into the authentication process for that application, send it to a known device for the user and be doubly sure that they are who they say they are.  With EmpowerID, this two factor authentication can be added into any SSO workflow and even be based on the user's role.

Save your users time while increasing your security seems like a win-win situation with single sign on.  Schedule a demonstration of EmpowerID's complete SSO capabilities and/or download our whitepaper on the Top 5 Federated Single Sign On Scenarios.

There is a saying in Identity Management: "What you can't automate, delegate."  It may be something that only I say, but it should be said more often.  Because following that credo improves security, productivity and the bottom line.

The project list of things to automate is a mile long, starting with user provisioning and permissions, group and role memberships, identity synchronization, and so on.  For delegation, the list is equally as long -- password reset, group membership, single sign-on, cloud accounts, and the lowest hanging fruit: Active Directory self-service.

Active Directory is a tricky beast, there are parts of it you need to completely cordon off.  You can't let anyone mess with the OU structure or change their own title or delete user accounts.  But you do want them to update their own mobile phone number, change the title of the user reporting to them, join a distribution group, or update their password.  Within ADUC, it's all or nothing, there isn't a way to manage it granularly like this.

The key to any AD self service solution is to have controls in place; an RBAC policy that defines who can do what without undue amounts of configuration.  You need to be able to define who can do what action (change a password, update phone numbers, create a group), who needs to approve it, and what is even shown to each user.  Having a dynamically maintained role structure and Rights-based approval routing (RBAR) allows you to have this level of granularity.

EmpowerID's HTML5 user interface means that updates can be made from any device, its unique combination of RBAC and ABAC allows for very fine grained permissions, and RBAR means that you don't have to define every single permission for approvals, it is all handled within the system.

With all of this delegation power available from the self service interface, native access can be shut down to ADUC.  You can have admin roles, help desk roles, manager roles, user roles, and all of it managed dynamically.  No more accidental deletion of an OU because you had to give an intern access to ADUC to change a user's telephone number (true story).

What separates a full IAM solution from a point solution is what it does with this Active Directory information.  An IAM solution can take these changes to AD and flow them to other identity stores and applications.  For example, the phone number change can update the emergency contact list, a title change can update HRIS once an approval workflow is satisfied, a change in a security group can update a user's role in a cloud application.

I'm not sure if you noticed in this post, but this is all delegated or automated.  IT just configures it using EmpowerID's visual workflow studio and users and computers do the rest.  Delegate out this lowest hanging of all fruit, AD self service, and improve security, productivity and the bottom line!

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.

I have a long history with Active Directory group management and as much as I fundamentally believe that roles are better for access control, sometimes you have to bite the bullet and use groups.  The reason is that some applications use groups, Microsoft loves groups, and it's a concept everyone gets.

There are basically two types of group management: delegated group management and dynamic group management.  Each has its place. There is a third facet to group management where you manage resources and what groups have access to the resource but that is slightly out of scope of our discussion here.

In delegated group management, group owners are able to manage the membership of their groups and users are able to request membership in groups.  A helpful user interface is presented to make it easy for users to get themselves into groups.

Dynamic group management is all behind the scenes.  Based on what you know about your user(s) from any number of identity stores, you build rules that dynamically place users in the group.  For example, every user who is a manager in Marketing (based on title in Active Directory and department in HRIS) will be dynamically and automatically placed in the Marketing manager group.  Once they no long fit that equation (promotion or department change), they are removed from the group automatically.

There are two types of dynamic groups: hierarchies and standalone.  In a hierarchical group, you don't have to create each one, you set up the rules from the top.  For example, every department needs its own group, it would take forever to individually configure each, so you create a hiearchical dynamic group (like a family tree or org chart) that creates and manages membership for every department and title.  With EmpowerID, these attributes can be from any identity store.  Standalone are like the Marketing Manager example above.

This need for delegated and dynamic groups does not stop at Active Directory groups (distribution and security groups).  Within your organization you are going to have various flavor of LDAP groups, SharePoint groups, roles masquerading as groups within applications, as well as the AD groups.

Your solution needs to support both delegated and dynamic groups of all kinds.  EmpowerID does this with a highly scalable metadirectory (managing its own groups and roles) and highly configurable connectors that can project these groups into any of the types of systems and applications you need.

In fact, you can manage a role in EmpowerID that is projected as a group in LDAP or AD giving you the best of both worlds.  This flexibility gives you more options for managing groups with less configuration and work.

EmpowerID can easily help you manage all of your groups, not just AD, not just LDAP, not just SharePoint...it is a complete group management solution that promotes the benefits of role based access control without losing the inherent need for group management as well.

A picture is always worth a thousand words, schedule a personalized demonstration and see how to manage all of your groups quickly and easily.

I like to think that I am unique.  However, to my IT, security and identity teams, I am just a mix of sales, marketing, management and location roles.  Knowing those four things about me can generally define what system access I will need.

A properly built Identity & Access Management (IAM) infrastructure can determine which of these roles I am in dynamically based on attributes in my HRIS, Active Directory, and other identity stores.  For external users, the source of truth might be CRM or your supply chain identity store.  These attributes are everywhere and can easily be synchronized into a metadirectory like EmpowerID's that utilizes a hub and spoke model, giving you a full 360 degree view of all of your users' information.

Once you know everything about your users and the role(s) that they have, what are you going to do about it?  Provision user accounts!  Remember those four roles that define me?  Those also define what user accounts that I should have. 

My "person object" or "identity" in the metadirectory includes the role definitions and role based provisioning rules to provision these accounts.  It sees "sales manager in California" and knows that I need SalesForce, GoToMeeting, a soft phone and Dynamics AX accounts.  EmpowerID will provision these accounts and then link them to my "person object".  Once I no longer satisfy the conditions for having that role, my user accounts (not my identity) are de-provisioned.

Having a connector to each application allows the metadirectory to also inventory that application to determine if any changes are made natively.  If it finds a new GoToMeeting account that is not linked to an person object, it will evaluate "join rules" to join this account (or de-activate it if you want to discourage or deny native access).  If there is no person object to join it to, it will become an orphaned account and the appropriate admin will be notified.

This role based provisioning is exceptionally important for external users such as contractors or suppliers or customers.  All of these users are more temporal, coming and going more frequently.  If a supplier needs access to your Ariba procurement network, you want to give a lifecycle to that account, ensuring that somebody certifies or attests to the account.  Let's say for example that the procurement role needs to attest, perhaps you want to do a runtime check to see who the supplier's account manager is and only have them responsible.  This Attribute Based Access Control (ABAC) method keeps you from having too many roles while still giving fine grained permissions around either the initial approval or attestation of a new account.

As you are designing these role based user provisioning rules, you are probably mapping them on a whiteboard.  EmpowerID's visual workflow platform actually allows you to drag and drop shapes (identity actions such as provision account, go for approval, etc) exactly as you are drawing it.  Though it is most likely more colorful and exciting in EmpowerID!

Don't get stuck with user provisioning that doesn't take into account who your users are.  And certainly don't get stuck with a limited level of roles and identity sources.  Because even though every user can be defined by their roles, they are still most likely a unique blend of multiple roles.  Your user provisioning process should reflect that.

Read how EmpowerID's unique RBAC and ABAC hybrid model gives you more finely grained control over all things roles: from authorization to authentication to provisioning.

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.