All-In-One Identity Management and Cloud Security

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.

Windows has created a false premise that the best way to manage shared folder permissions is with groups.  You grant access to the folder by way of an AD security group, then users request membership in that group.  That's the way NTFS works but is it the way users think?

Users want access to a resource; they want access to a folder.  They don't want membership in a group.  Of course, they need membership in a group, but they don't know that.  So, why would you force users to ask for access in such a roundabout way?  It should be simple and the mechanism of how it is happening in the background shouldn't matter to your user.  The premise is: users will think of what they want access to and should be able to request it directly.

EmpowerID File Share Manager puts a 360 degree view of file shares in front of your user.  They can view what roles and/or groups they are a member of and see the resultant access to shared folders.  Or they can view the shared folders they have access to and see the roles and or groups that make that happen.

And, most importantly, they can search on folders to request access.  When they request access a few things happen unbeknownst to them.  If they are allowed access directly, they are granted access.  If a resource owner needs to approve access, it will route the approval to the owner and let the user know that it needs an approval before granting access.

EmpowerID does this by putting a user into a role which has access to that resource (shared folder in this case).  By putting the user in a role and not an AD group it saves the user from being a member of too many groups and ultimately getting token bloat.  Token bloat seems like a made up malady but it is bad.  The more groups your user is in, the larger their token gets.  At 1015 memberships, the token exceeds allowable size and the user cannot log in.  As it gets over 256 memberships, authentication slows down and kerberos has a tendency to lock up with some applications.

So, by managing your shared folders with a dedicated self service portal, your users will have greater and easier access to shared folders, request access in a more intuitive manner, control harmful afflictions like token bloat, and reduce your dependence on an outdated technology like groups.

But you really don't stop there.  That same self service portal can be used by the resource owners to see who has access to their resources (even if granted via groups the old fashioned way).  They can grant and revoke access to their folders either by searching from the user or the resource.  Most importantly, they can attest to the correct access from the resource side on a regular scheduled basis to meet auditing requirements.

Speaking of our friends the auditors, they might be even more resource oriented than the users.  They need to track who has access to a resource and it costs you money and time to have them try to disentangle all of the resultant access from nested groups.  Having them look directly at the resource is, after all, what they need.

Think about the problem of groups from their perspective.  If a group is giving access to a shared folder, what happens if you're also using it for another purpose and people just keep getting added to it.  Your auditing friend wants to be able to see that easily.  EmpowerID solves that issue in another way, too. 

We use hidden system managed groups and use them in a way that maximally reduces token bloat.  The goal is to reduce the number of groups created to assign permissions and to completely control the membership of these groups so people can’t use them for other purposes and add members which would inadvertently grant access to the folders.  We reject any outside additions or deletions of user to these groups.

The debate has raged for years on groups vs. roles, especially with regard to Active Directory and Windows permissions.  The answer is easy: using groups is the old way; using roles is the new way.  Using groups is letting the technology manage the way you do business.  Using roles is making the way you do business lead the technology.  Especially with shared folder permissions.

What goes up must come down.  For every action there is an equal and opposite reaction.  Every user provisioned is eventually deprovisioned.  It's the circle of identity, a term I just made up.

At its core, the concept is simple.  In practice, it is a lot of work.  Microsoft published a statistic at one point that the average user is provisioned in 16 directories when hired yet only deprovisioned from 9 upon dismissal.  That is 7 directories worth of identity floating around your enterprise for a user that doesn't exist.

Provisioning has to be automated and deprovisioning has to be tied to that process.  The obvious automation that you need is to have both processes tied to your HR system.  The logic is simple, if you have a hire date and no fire date, you should have a user account.  But the flaw starts when you have multiple connected systems, both cloud and on-premise.

If you were hired as the receptionist, got promoted to a coordinator and ultimately a manager, you should and will have different accounts in different applications for each of those stages of your career.  Upon your termination date, your identity management system needs to know which accounts you currently have to properly deprovision you.

In effect, you need constantly updating role based provisioning to keep up with your ongoing provisioning and deprovisioning needs.  These roles will constantly update not only your resource access but your application access as well.  Think of it like a key ring, take the old ones away when you add new ones.  You are much less likely to have those extra 7 accounts on your last day.

To keep all of this in synch, your identity platform needs the concept of a person account which joins all of your user accounts to you.  EmpowerID's metadirectory performs this function giving a full view of all of a user's accounts tied to their person record.  So after the three promotions and constant turnover in that user's lifecycle, upon their termination date, you have a clear record of all application accounts, and can deprovision ALL of them, both on premise and cloud.

Think about this term: lifecycle.  Because not all users are managed by a set of hire/fire dates.  Contractors, temps, external partners, customers.  HR cannot be expected to keep a good record of the hire/fire dates of these users, yet they still need access.  Again, not just to the network but to individual applications.

The EmpowerID metadirectory allows you to put start and end dates on any access to any resource, keeping the access from living forever.  Upon hitting the end date, simply renew or let the access expire.  The same thing applies for attestation, you can have the owner of a resource attest to all users who need access.  Or you can have the owner of the identity (manager, account manager, etc) attest that the user still needs each level of access granted.

The metadirectory's join engine and provisioning and deprovisioning workflows automate provisioning and deprovisioning.  The attestation policies keep exceptions from slipping through the cracks.  This keeps the user account store from going up without going down.

If you want cloud SSO, you need cloud provisioning.  This isn't a brilliant revelation...your users can't log in to an account they don't have.

Let's take my favorite and most frequent use case: the wild world of Salesforce.com!  You want your users to be able to authenticate into salesforce without having to re-enter credentials or, worse yet, enter a completely different set of credentials.  So you federate with Salesforce.

Your user authenticates into the network using either her Active Directory or EmpowerID credentials.  She clicks on a link to salesforce and it quickly and invisibly redirects to the EmpowerID Secure Token Service which sends a SAML token to Salesforce which then accepts it and our intrepid user finds herself in Salesforce authenticated and ready to do work.  Without entering any additional passwords or user names.  Like magic, sweet federated magic.

The trick to this is your user needs a salesforce account.  And EmpowerID (or any other identity provider) needs to know what that user's account is.  Without automated cloud provisioning, do you manually provision each account?  Do you have each user claim their account to register it?  Do you put users in AD groups to establish access and hope against all hope that that group stays accurate?

Or do you integrate cloud provisioning with cloud SSO?  This way, users are provisioned and de-provisioned...automatically associating EmpowerID (or some other identity store) accounts with the Salesforce account?  Giving them the SSO experience when they should have it and removing that capability when they should not.  And, reducing the steps needed for users to get this capability.

So, what about existing users?  Do you have each user go and claim their account?  Users hate to follow IT instructions, we all know that.  So let's inventory salesforce.  All you need is a key (such as email address, conveniently your salesforce user name) and you can associate each of your corporate accounts to their salesforce accounts.

And the result, cloud SSO.  And made all the easier because of the connection between cloud SSO and cloud provisioning.  I have written extensively about this, about the connection between all aspects of identity and access management.  You need your provisioning to interact with your access governance to interact with your authentication to interact with your password management. 

IAM is a complex beast to slay, especially with the newer cloud aspects of today's world.  Having a complete platform that can be implemented in phases but still work together solves this and makes this beast much more manageable.

Let's start with the cloud.  Let's get your cloud SSO and your cloud provisioning working together.  Take a look at the federated SSO whitepaper and then schedule a demonstration of how EmpowerID will get your users provisioned and SSO'd to the cloud.