All-In-One Identity Management and Cloud Security

You have heard the statistics that over 30% of all help desk calls are password related and that each help desk call costs, on average, around $35.  It is true that the quickest and best way to increase the efficiency of your IT department is to offer self service password management.  Give your users the ability to unlock and reset their own passwords.

Just don't stop at Active Directory.  There are more passwords out there, a lot more.  A study of just web passwords show that users have on average 6.5 passwords to remember for 25 accounts.  Never mind that to get a half password, you have to have a very lax password policy (4 characters, 1 of which must be a fraction!).

So if you can save your company a quadrillion dollars solving your AD password management issues, doesn't it stand to reason that you want to solve ALL the password management issues.  Your users forget them all, might as well have them reset and unlock them all.

Password synchronization goes hand in hand with self service password reset.  The first benefit is that your user's range of passwords is simplified, that number of 6.5 goes down dramatically to as low as 1.  There are times when password complexity rules are mutually exclusive and you will just have to have that accounted for in the password synchronization rules.

The one password most users remember is their AD password because they use it so often.  Make that your catalyst for all password changes.  If that password is changed, have EmpowerID synchronize that password to all of the other applications.  Even if the password is changed natively through CTRL-ALT-DEL, EmpowerID can capture that change and synchronize it to the other apps.

If the user does forget the AD password, offer a variety of ways for the end user to reset the password.  Utilize the tried and true Q&A knowledge based questions, enhance the security a bit by throwing in OATH tokens, and be sure to have a helpdesk only question where the helpdesk can see both the question and answer.

Be sure to lock down the ability for end users to natively change passwords in the applications that you are synchronizing.  EmpowerID will update the application password next time your user changes it but they will be out of synch until then.

If you focus on a solution for only the AD passwords, you are going to drop that 30% down but not all the way to 0%.  To get to 0%, you have to offer self service password reset and password synchronization to stop "ALL THE HELP DESK CALLS!"

Simple attribute sync is not difficult.  Take a key (user's alias or email address or employee ID) and decide which identity store is authoritative and synchronize the attribute(s).  What is difficult is when you have dozens or scores of identity stores.

If you tried to synchronize all of these attributes without a central identity store like a metadirectory, you would end up with a confusing lattice of synchronization scripts that could easily conflict with each other.  I'm not saying it's impossible, it's just impractical.

Having a hub and spoke solution allows you to easily flow attributes from the authoritative source to the metadirectory and back out to the appropriate identity stores.  An example would be that HR is authoritative for a user's title, then empowerID metadirectory would inventory HR, see the change and update the user's "person" account in the metadirectory.  With that change, it will need to be flowed out to the LDAP identity store and Active Directory.

If some rogue admin changes the title in Active Directory using ADUC, empowerID would inventory that change, see that HR is authoritative and roll back the change in AD.  Having the central metadirectory is incredibly powerful for keeping attributes in all identity stores accurate.

But metadirectories are complicated, right?  I saw my first metadirectory in 1999/2000 when Critical Path bought Isocor.  If you asked me that question then, I would have said, "yes, very complicated."  Ask me today and I'll say that even I can manage connectors and attribute flow. 

Consider this:

It is as simple as configuring the arrow to indicate the authoritative source.  It can be authoritative from either identity store (arrow facing one way), last change wins (arrows facing both ways), or don't sync (big red dot).  "Big red dot" is a technical term in the world of UI, trust me.

You have these attribute flow rules for every connected system in the identity ecosystem.  From the example of the hub and spoke diagram above, you would have four attribute flow rules to fill out, with empowerID doing the heavy lifting of schema detection from its connectors.  You just decide what maps and what wins.

This is just for simple attribute flow, sometimes it does get more complicated.  You may need advanced attribute transformations, more than 1 to 1 attribute flow, 1 to many, calculated values.  You may need to extend the attribute flow for complex transformations.  EmpowerID's UI allows you to easily extend the flow with these transformation, some right out of the box (for example first name & last name from HR transforming to an alias like first initial last name {Edward Killeen becoming ekilleen}) and some with custom code.  It is all built into the empowerID platform.

Having a metadirectory in place also extends attribute sync to the cloud.  Many of our customers have 20%+ of their applications in the cloud now.  You need to be able to synchronize these attributes out to the cloud identity stores.  You rarely have access to the backend database or directory, rendering scripts and simple synchronization tools obsolete and ineffective.

EmpowerID's connector framework can map synchronization actions to its API layer, allowing synchronization from the metadirectory to the cloud applications.  With this capability, you now have all of your identity stores synchronized and accurate.  Contact us for a personalized demonstration of empowerID and we can show you how to synchronize attributes and all of the other capabilities of the most complete and flexible IAM platform on the market.

Wouldn't it be magical if a user forgot their Active Directory password, reset it themselves and had that new password synchronized to all of their other accounts?  You know, without calling the help desk?

Think of the productivity gains if that JIRA account they go into every 3 months had the same password as Active Directory as Google Apps as Salesforce as that custom built app that nobody knows who supports?

Currently, we know that over a third of all help desk calls are password related and to properly maintain security, password policies should actually be more stringent.  This would cause that number to go up.  It's not the users' faults, it is human nature to forget even the most important things.  Otherwise grocery lists wouldn't exist and there wouldn't be jokes about husbands forgetting anniversaries.

Since we can't blame the user, let's help them.

Self service password reset is a very basic idea.  If your user doesn't know their password you have to authenticate them with at least one of three things:

• something they know
• something they have
• something they are

The first is knowledge-based, usually a set of answers to pre-set questions.  Making this customizable by role is important; your factory floor worker may not need the stringent set of questions that your CFO needs.  It is sort of like making the punishment fit the crime, the more access that the user has, the more important it is to determine their identity.

The second factor is usually a phone or smart card.  This one isn't as common as it should be.  As in the first factor, you can customize this by role, take advantage of the fact that your executive users all have smartphones, send an OATH token to confirm that they have what they say they have.  It adds a LOT of security and only a small additional commitment from the user.

The third factor is usually biometrics.  This step is often taken for extremely highly sensitive accounts.  If you have the need to roll this out, your users know what they are dealing with.

EmpowerID Password Manager can handle all of these factors and the customization needed to make it work.  Its powerful workflow engine makes it easy to branch out different password reset paths based on role or group membership or any other determining factor.

And EmpowerID also synchronizes this new password with all of the other systems connected to its metadirectory.  Reset you Active Directory password and simultaneously reset your Lotus Notes password.  Give your users one password at a time to forget.

Importantly, users are going to reset their password the old fashioned way with CTRL-ALT-DELETE.  EmpowerID has a DC filter that will catch these password changes and run them through the same password synchronization workflow described above, keeping your users with just that single password.

By having tools to help your users, you can put password policies in place that help security, making them change every 30-45 days, knowing that you won't get as many complaints since it's a single password still.  Something that even your most vocal users should get behind.

EmpowerID makes all of this possible in a very powerful yet easy to manage application.  It has at its core a full Identity & Access Management platform broken out by modules for functionality.  Having the metadirectory, RBAC engine and workflow studio built into the base platform and available for every module gives the flexibility to have these advanced password functions without having to buy the entire IAM suite.  See it for yourself, schedule a demonstration by clicking the button below!

I'm on the phone all day every day with clients who are either manually provisioning users or cobbling together scripts with bandaids, duct tape and chewing gum to get their user provisioning automated.  If you don't have it fully automated yet, you are not the lone ranger.

That does not mean that you shouldn't, obviously.  User provisioning should be automated, it should incorporate all of your applications (cloud and on premise) and it should tie into your access governance as well.

Let's start with the first part: automating your user provisioning process.  This is basic identity management workflow.  In the case of EmpowerID, it is VISUAL identity management workflow, meaning that the workflow is designed and configured in an easy to manage and visualize visual business process management layout. 

When you are sitting in a conference room designing the provisioning process, you are most likely at the whiteboard drawing rectangles and arrows and directories.  That should translate directly to the identity process workflow in EmpowerID, allowing your business needs to dictate your identity policy instead of your identity software dictating your business.

The identity management system will have connectors to all of your applications and identity stores.  Usually, HR is your authoritative system of record; EmpowerID will inventory HR for hired or fired employee records and initiate the onboarding and offboarding workflows.  The user account will be created in the metadirectory and based on the rules and policies in EmpowerID, will initiate workflows to all of the other affected systems and applications that this user should access.

The metadirectory sits in the middle and keeps a centralized record of all of the user's accounts and access.  This "person record" gives a whole view of the user and allows for auditing, constant updates to attributes and resultant access (whether it be roles or group membership or application access).  This makes auditing easy, makes it possible to see changes that happened outside of the system (through native access), and allows for attestation and separation of duties policies.

Those internal users aren't all of your users though.  You have partners, customers, dealers, contractors and a host of other external users.  The old "keep them in AD" practice won't work, there is too much risk there.  EmpowerID's metadirectory and workflows give you the ability to keep user accounts in the same system, design similar workflows and manage rights and access in a much more secure manner.  You can even have anonymous workflows to allow external users to create an account with limited access and send requests to internal users to grant additional access.

And, to just what applications are you provisioning users nowadays?  Certainly more than you were five years ago.  You have cloud applications, AS400 applications, web applications, and the usual suspects of AD and Exchange.  You need a modern IAM provisioning software (like EmpowerID) that can handle provisioning to all of these applications.  EmpowerID has direct connectors to most major applications and the ability to map APIs to workflow shapes for ones that we don't.  Most importantly, by having a framework to quickly deploy and manage connectors, EmpowerID can connect to almost anything, keeping user accounts current and secure.

The third part that is important is to integrate with all other aspects of Identity and Access Management (IAM).  Most legacy applications (I'm looking at IBM and CA and Microsoft and Quest here) are the result of myriad acquisitions and mergers and the products are put together in a way that not all modules work together.  EmpowerID is built from the ground up on a single code base and the platform shares common components like the metadirectory and RBAC engine and workflow studio. 

So, if you are provisioning to the cloud, you can create role based provisioning so only salespeople get a CRM account and they are automatically federated for single sign on and application roles.  When you reset your password in AD, it flows and resets passwords in all applcations.  If your user is promoted, this reflects throughout their identity, changing application access and roles within the application.  If a user attempts to access a highly secure folder, a second factor authentication can be launched to ensure they are who they say they are (and have what they are supposed to have). 

It needs to be a full identity ecosystem.

So, automate your user provisioning process but do it with an identity ecosystem that covers all of your identity needs.  Even if you don't deploy all of it right away, have a platform that can handle all of your identity needs.

Looking at the title of this blog post, you would think, "that's crazy, there are no roles in SharePoint!"  Microsoft liberally uses SharePoint groups to mean roles in their documentation, but these groups aren't useful in any RBAC manner beyond SharePoint.  SharePoint can also utilize Active Directory security groups, but there is a downside to this with token bloat and the accidental mixing of permissions between SharePoint and AD (add a user to a group to grant access to a SharePoint site accidentally gives them access to the deepest darkest secrets in accounting).

Groups are not roles.  Especially when they are static by nature.  Over 85% of organizations manage groups manually, you can never really be certain that the correct users are in the correct groups if that is the case.  You need your roles to be dynamic and rule-based.  You need your RBAC to be augmented by ABAC for on the fly fine grained permissions.

So, how do you do this in SharePoint?  By setting EmpowerID as your claims provider. SharePoint Claims providers add claims to the security tokens of users when configuring permissions on secure objects like lists, sites, items, and documents.

This gives you the ability to expose your roles in the People Picker to find and select people, groups, and claims when a site, list, or library owner assigns permissions in Microsoft SharePoint Server 2010. When claims-based authentication is used, the People Picker allows end-users to search and select claims for permissions assignments from a custom Claim Provider or Claims Augmentation provider just as they would normally search for users or groups. Typically a Claims Provider would support more flexible role-based assignments or dynamic fine-grained authorization assignments to increase the flexibility and security of the SharePoint permissions system.

In EmpowerID's RBAC engine, roles are assigned dynamically, either by set groups or a role structure (location/department, etc).  The role structure is polyarchical and is generated based on your applications and corporate structure.  Powerful RBAC policies leverage EmpowerID’s multi-tiered model to pre-calculate access to all known enterprise applications and resources based on an organization’s structure, a person’s job function, and all directly assigned access. These rules allow information from authoritative systems to drive changes in application access and provisioning policies.

What you end up with are roles that can be applied to any application, access or provisioning policy.  The role membership is updated dynamically based on changes in identity information from any connected identity store (HR, customer database, Active Directory) and inventoried as often as every couple of minutes.  And, very importantly, used to manage SharePoint permissions without having end users have to manually update AD or SharePoint groups. 

Think about that, SharePoint permissions that stay accurate without you having to manage it!

These permissions can be assigned as Administrator, Contributor, Reader or any level of access within SharePoint.  When the user signs in, the EmpowerID claims provider will pass along a claim with all of the user's permissions within SharePoint.  You can even use EmpowerID for SharePoint single sign-on for external or internal users.  The same process applies and you won't have to give an AD account to the external user.

Make SharePoint work by managing SharePoint roles dynamically.  If you want a demo, we would be happy to show you how this works by clicking here.  Or click the button below for a whitepaper on our method of managing permissions with an RBAC / ABAC hybrid.

There is no need to choose between RBAC and ABAC.  A case can be made for each individually and certainly a case can be made for RBAC (role based access control) and ABAC (attribute based access control) working together.

RBAC is definable, the user is a member of a role or isn't.  If the user is part of the dental chair warehouse worker role, then they are granted access to resources that role needs.  This role membership handles the user's coarse grained access...what files and folders they can access, in what applications do they have user accounts, what group memberships they have.

Most access can be granted at this level, RBAC can be applied to almost every identity action from role based provisioning to role based authentication to role based authorization to role based administrative policies.

These role memberships are all definable and, most importantly, auditable.  Your audit and security reports will show what roles a user has and, conversely, what users are in each role.  You will have an audit trail of every action these users do via their roles and what each of these roles can do.

EmpowerID grants these role memberships during the provisioning lifecycle process.  As a user is provisioned, the roles are granted dynamically based on attributes in any connected system (HR database, Active Directory, ERP system, union membership database).  This dynamic role membership is maintained during a user's lifecycle as their job title, department or anything else changes, so does their role memberships. 

Users can also request access to roles or request access to a resource that puts them into a role.  Self service role management is powerful if the correct controls are in place, with workflows and approval routing mechanisms.  Temporary roles can also be administered in this way, where a user requests access to a customer folder for 3 days.  And, like all role memberships, it is auditable.  You will know who had what access and when.

But, as we started in this discussion, there is a world where roles are not fine grained enough.  You don't want to have a situation where you create a role for every single possible permutation of access needed.  Role bloat like this would be unmanageable and unauditable.  You would end up with more roles than users.

So, what do you do for the finer grained authorization that you need?  Combine RBAC and ABAC.  A user is a member of a role based on access provisioning policies.  But, at runtime when accessing a resource, you can further define that access by ABAC, checking on an attribute that you know about the user in real time.

Let's use that example of the dental chair warehouse worker.  This worker needs access to a particularly sensitive section of your ERP system to order a gold plated footrest on the top of the line dental chair.  But, your security team insists that the warehouse worker should only be able to access ERP during his shift.

Most warehouse workers exchange shifts, take extra hours and vary their workweeks constantly.  You cannot just make a swingshift warehouse worker role and know that it's accurate for every worker every time.  So RBAC handles the coarse grained permission that our user is a dental chair warehouse worker.  When the worker goes to access the gold plated footrest in ERP, EmpowerID checks that the user's role gives him access, then at runtime, checks the time management system to see if the user is on shift right now.  If so, boom, access.  If not, boom, security alert.

If you tried to manage an example like this with just RBAC, you would have a role bloat issue leading to user and help desk revolt.  If you tried to manage this with just ABAC, you would have an auditor and network performance issue, leading to executive management and user revolt.

A hybrid of RBAC and ABAC streamlines this, gives you the ability to manage most permissions with a coarse grained role and the rest with a fine grained attribute.  EmpowerID is built from the ground up to handle these two concepts together and seamlessly.

Users and their access are inextricably linked.  The National Institute of Standards & Technology (NIST) estimates that users are only 58% productive without their proper access.  So, why are provisioning processes often separate from access governance processes?

It should be an identity ecosystem.  When a user is initially provisioned from HR (or a contractor database or a customer self-registration), you apply an initial role to that user dynamically based on what you know about them.  That role (or roles) determine in which systems the user needs to be provisioned.  An example is: sales rep in Toledo will need an Active Directory account, an Exchange mailbox, an ERP account and a salesforce.com account.

Once that user has these accounts, the user will need to have roles within these applications.  The ability to modify groups, access SharePoint sites, place customer orders, modify CRM records and anything else that is role based.  This is the idea that you are provisioning access and accounts.

Some systems, like your VPN or shared folders or Business Intelligence app, may use AD groups to grant these roles.  And this is why provisioning access goes beyond just the application role based access control listed above to group based access control.  No organization can manually keep up with all of the group membership requirements that is required; you need to provision group membership dynamically based on rules and roles. 

Groups are intertwined in your everyday corporate life, from distribution lists to printer access.  However, role based access control is arguably the more modern approach to access governance, reaching outside of the Microsoft ecosystem better and being generally more flexible.  Having group membership controlled by your role makes this easy.

This can all happen dynamically in the first minutes of a user's employment, but users don't sit still for much longer than that.  Estimate vary, but on average, there is a 20% internal turnover per year.  These are employees that are still with the company, but have some sort of job change whether it be a redeployment, promotion, move, or restructuring.  Then the whole identity and access provisioning scenario starts again.

Having a metadirectory sitting in the middle of this identity ecosystem gives you flexibility to inventory HR or AD or any other authoritative source or sources to detect these changes.  Once the change to a user happens, all of the application provisioning can be re-evaluated, de-provisioning accounts they no longer need, provisioning new accounts and changing roles within the applications.

Group memberships get re-evaluated, removing access to old and granting access to new.  EmpowerID can generate reports to show new resultant access for the new roles for auditors or new managers to review.

Then if an offboarding event does happen, all accounts and access are linked to an EmpowerID person object and can be removed in one fell swoop, with accounts de-activated and an audit trail to show access has been removed from everything except their 401K account.

Too often, provisioning is looked at as a way to create an account without considering that access is as important as the user accounts.  Then the lifecycle of the user needs to be considered, again not just as an account but the role and access level required.

EmpowerID's unique visual workflow component, metadirectory and RBAC engine work together as part of the IAM platform to keep privisioning, evaluating and re-provisioning user accounts and access throughout a user's lifecycle.

A pride of lions. A gaggle of geese. A mob of wombats. An Active Directory Security group.  

It’s natural to group things and your users are no exception. Many organizations have more groups than users, a user can be a member of hundreds of groups. We’re talking AD security groups, distribution groups, LDAP groups, SharePoint group, and roles.

We know that 81% of organizations manage these group memberships manually, expending an amazing amount of resources to keep them accurate. If they keep them accurate.

There is something that can be done about it…automate and delegate. Automate the group memberships with dynamic groups. Delegate to group owners the ability to manage their own memberships. Delegate to users the ability to join groups. And put workflow controls in place to keep it organized.

EmpowerID has two methods to manage Active Directory groups dynamically, by roles and by set groups.  The benefit of each is that they can be used across a wide variety of identity and access governance functions: from provisioning to SSO to access control.  And both methods can be used to manage Active Directory security groups dynamically.

Even using the more advanced method of managing permissions with roles, you will still need AD groups, both security and distribution.  And EmpowerID gives you both of these methods to keep your group membership accurate, dynamically. 

This first video explores how to use the roles that are pervasive throughout EmpowerID's Identity Management suite to keep group membership dynamically updated.

In addition to the role based method, set groups can be created in EmpowerID that will manage the group's membership.  As with roles, these set groups have additional functionality in all aspects of IAM from authorization to authentication.

Group management is only a part of EmpowerID's full Identity and Access Management capabilities. EmpowerID's robust IAM platform is built modularly, so you can solve the business problem of today while laying the foundation for future IAM capabilities. 

Take a look at the dynamic group videos and schedule a demo. Save money while improving security and productivity.

Identity and Access Management is all about the authoritative system.  The identity source of truth.  Most often it is the HR system, but for some very important information it is your users.

What you can't automate, you delegate.  And this is especially true for user identity information such as mobile phone, home address, or other personal identity information.  Your end users know this information, you and HR probably don't.

The solution is to give them Active Directory self service.  Delegate the ability to update pertinent identity information in AD but only the pertinent information.  You will need role based access control to determine what the end user can and cannot update.  Let them view title but not edit it.  Allow them to update their office phone but put an approval workflow in place for their manager or the help desk to confirm it. 

But this information belongs in more places than Active Directory.  If your user updates her home address, that information should flow to your payroll application.  If mobile phone is updated, that should flow to your emergency contact list.  Identity is a lot more far reaching than Active Directory, but AD is the place that your users understand; it's the global address list, they see it all the time.

Some information goes the other way.  Your user gets a promotion and the new title is put into the HR system, that information needs to flow to Active Directory.  That same promotion prompts the user to need access to the customer portal and that information flows directly to that portal, provisioning an account if necessary.

Having a metadirectory functioning in a hub and spoke model allows you to configure these attribute flows easily and efficiently.  The EmpowerID metadirectory gives a visual attribute flow to determine which identity store is authoritative and which is a recipient.  You can also have a "first wins" scenario, taking the last change regardless of which system is the originator.

The metadirectory "hub" keeps a record of all changes, allowing you to audit which system recorded the change, when where and how.  You can roll back changes, apply additional workflow actions to any change, and audit these changes periodically.

The idea of adding a workflow to an automated change might seem counterintuitive but the idea is to have identity controls in place for applications that don't necessarily have controls.  Active Directory is a great example.  If you have ADUC access, you have ADUC access.  You want to have role based access where users can manage some attributes, managers can manage more, the help desk even more, and the admins to have more access.

Having a check and balance on each of those powers is important.  Think about this, the users with the most privilege (domain admins and senior executives) also have the most ability to bypass your security.  If you ran an audit on users with passwords set to never expire, the list would most likely be littered with names from those two sets.  And, they are the users you need the most secure.

So if a change comes from ADUC into the metadirectory on a particularly important attribute (say, relating to password policy), put a control in place.  Have another domain admin approve it even though it was an automated feed.  Same thing for title, kick off a workflow when someone's title change from HR contains VP or "Chief".  This is simple checks and balances just like we all learned in the 5th grade.

The metadirectory gives you an easily managed model to flow identity information to the correct identity stores.  It allows you to automate AND delegate.  And, it enables auditing to a level that native application access won't.

Listening to a Gartner webinar on Identity & Access Management this morning, this line struck me: "Cloud breaks legacy IAM approaches".  Because it is true, most legacy IAM vendors are stuck with old codebases, old products, and components that have been cobbled together to form "frankenproducts".  They have no more chance of seamlessly managing cloud identities than they do of installing and configuring on time and on budget.

Cloud identity management is hindered by these old legacy approaches to IAM.  The industry is, in many ways, in the exact same position as it was ten years ago with on premise applications.  The solution to each cloud problem (SSO, provisioning, access governance) is met by a different vendor, or a different product within the legacy vendor's "suite".

In the webinar, Gregg Kreizman says that the larger vendors "have been able to provide functionally across the IAM function set through acquisition, through some development.  They have slowly and somewhat shortly have been incorporating these things into suites, some of them very loosely integrated some of them better than others."

The problem, though, isn't the legacy IAM vendors.  The problem is that it's easier to justify a legacy IAM vendor to your CFO, despite the higher cost and lengthy deployment.  Gregg also says, "I hope no one would base election or implementation decisions based on identifying the largest vendors only."  For the exact reasons above.

Because there are approaches to the cloud that isn't burdened with tons of legacy baggage.  To a newer, more modern IAM platform, that cloud application is just another identity store.  In some ways, even easier to work with due to its requirements for SDKs and APIs.

Having a platform that integrates easily between cloud and on-premise brings you up to date in Identity & Access Management.  EmpowerID has connectors to most major cloud applications and a flexible connector platform to build new ones for others.  Provisioning, deprovisioning, updates are all seamless and fit into your IAM workflows the same as an on premise application.

But that isn't what breaks most legacy applications, it's the integration of IAM functionality.  Provision a cloud user AND provide cloud single sign-on.  Role based provisioning for cloud applications that integrates with role based adaptive authentication for cloud applications.  These are the things that test your ability to manage identities in the cloud.

Chances are the legacy IAM "frankenproduct" cannot do that for on premise applications, much less the cloud.  The only way to make this sort of modern IAM functionality to happen is to have a purpose-built, single codebase IAM platform.  One that can easily have the roles engine speak to the workflow engine speak to the metadirectory.  One that can insert a second factor authentication shape into an access authorization workflow.  One that can provision any number of cloud or on premise applications within a single visually based workflow.  In short, EmpowerID: the modern IAM approach.

That is a list of the capabilities of EmpowerID.  The same platform manages all of this functionality.  What changes is the workflow shapes (think of them like identity management actions) that are exposed by module.  For example, if you have the User Manager and Group Manager modules, you can insert a dynamic group membership provisioning shape into your user provisioning workflow, allowing provisioning to extend to groups.  If you have User Manager and SSO Manager, you can check a user's role and demand additional authentication before passing them along to the cloud application if the role and application mix is identified as highly secure.

The cloud doesn't have to break your IAM.  In fact, IAM is too important to let it.  What you need is an approach that is modern, flexible and built to manage change in both identities and your business process.  Seeing is believing, we can demonstrate IAM that extends seamlessly to the cloud with EmpowerID.  Schedule a demo and you will never think about going back to those legacy IAM approaches.