All-In-One Identity Management and Cloud Security

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.

Gartner says that while only 38% of businesses use cloud applications today, 80% plan to deploy cloud services in the coming 12 months.

That is astounding.  If you are one of the 55% of businesses planning on deploying cloud services for the first time in the next 12 months, you have some planning to do for your users and Identity Management (IdM).

The first two Identity Management hurdles you have to overcome are provisioning and Single Sign-on.  Without proper IdM planning you could very easily end up back in the dark ages of manual provisioning for your cloud applications.

Say, for example, you are a personal fitness firm deploying Office 365 service to your personal trainers.  these trainers don't necessarily have Active Directory accounts so you cannot rely on Dir Sync (even if there weren't other limiting factors like multiple forests).  Same thing with Google Apps and GADS (Google Active Directory Synch).

You can either manually add all of these accounts and commit a metric ton of resources to updating their accounts on an ongoing basis, write a script, or invest in an IdM platform that combines on-premise and cloud provisioning.

Very few cloud applications get deployed to everybody, so you need to offer role based provisioning.  In our example, if role=trainer, it should kick off the workflow to provision an O365 account.  If role no longer equals trainer, de-provision the account.

EmpowerID manages these automated provisioning workflows with its metadirectory.  It populates "person" accounts in the metadirectory based on the authoritative source or sources, determines the user's role based on identity information we know about them (department, title, et cetera), and then uses a connector to natively speak to the cloud application, provisioning an account and giving the proper permissions within the cloud application.

The exact same platform and workflows and roles are used for both on-premise AND cloud applications.  Just a different connector and different role based provisioning rules.

I used an easy example, but any cloud application works this way.  Even when the authoritative source is a cloud application (for example, Workday or NetSuite).

So, there is half the battle, you have user accounts but how do your users get there?  Nothing like having half a dozen URLs, half a dozen passwords, and a deluge of help desk calls!  You need single sign-on, most likely federated single sign-on!

Most of these cloud applications support Federation using one of the standard protocols: SAML, OAuth, OpenID, WS-Trust, or WS-Fed.  For those that don't, you still need a method for secure password vaulting.

EmpowerID offers a single unified SSO dashboard for both on-premise and cloud applications.  It includes applications that are federated, using Web Access Management (WAM), password vaulting, or even authenticating with EmpowerID's virtual directory.

Given the increased need for security around cloud applications, EmpowerID provides an OATH server for two factor authentication (TFA), device registration and a full auditing capability.  TFA can be employed based on the role of the user, the security level of the application or a combination of these two.  If you are giving users access to your business applications when outside the network, make sure you know who they are.

Having the integrated metadirectory and automated cloud provisioning, you do away with the messy Active Directory requirements of some SSO providers.  Being a complete integrated single codebase IdM platform adds more functionality to the cloud equation than you can possibly get with piecemeal solutions.

Schedule a demonstration of automated provisioning or just read our whitepaper on Federated Single Sign-on and see how EmpowerID can solve the identity problems you will encounter as you move to the cloud.

You can manage access to Microsoft Dynamics AX with Active Directory security groups.  But you can only get so far.

A manufacturing client of ours has very specific and extensive needs for Dynamics AX.  Of course, they need to provide access to employees but they also need to have dealers, suppliers and other partners to have access.  Once in Dynamics AX they need to take advantage of the internal roles to ensure that the right users have the right permissions.

Security groups seem like the best fit from 30,000 feet...both AD and Dynamics AX are part of the Microsoft stack.  Microsoft has set it up so that if you are in a specific security group for Dynamics AX , you can authenticate and use Dynamics AX.  But they stopped there, close but not close enough to actually use the solution for our client's needs.

Two things in our client's use case preclude them from using groups: the external users and the specific roles within Dynamics AX.  They have absolutely no interest in maintaining AD users for these external dealers and suppliers.  And they want to take full advantage of Dynamics AX and have different roles within it.  The whole idea is to be automated, not have to go in and manually assign permissions once a user has been put into a group.

So, what do you do?  EmpowerID.  A full IAM suite will give you the three components you need to manage Dynamics AX access correctly. 

You need a flexible connector that speaks to Dynamics AX using AIF.  Microsoft Dynamics AX Application Integration Framework (AIF) enables companies to integrate and communicate with external business processes and partners through the exchange of XML over various transport media. AIF enables both business-to-business and application-to-application integration scenarios.

EmpowerID's metadirectory gives you an identity store for your external users separate from Active Directory.  These users can then be provisioned into Dynamics AX using the connector and given the appropriate permissions and roles.  These roles and user lifecycles are managed in EmpowerID.

EmpowerID's RBAC engine gives a flexible and powerful polyarchical role structure.  You can manage your roles dynamically and map them to Dynamics AX, giving the exact permissions you need.  All role assignments and Separation of Duties (SOD) is managed in EmpowerID so you can attest, certify and automate all of the processes you need to manage access.

So, when do you use groups?  When you want to give vanilla roles to a set of users that are all in AD.

When do you use roles?  When you want to manage a diverse set of users with a diverse set of access permissions in Dynamics AX.  And when you want to automate it without dedicating a help desk person to managing it manually.

Most organizations using Dynamics AX have business, compliance and auditing requirements.  They are using it because they need to manage critical business processes and business data.  Not using roles to grant correct permissions seems to work against the investment they have made in Dynamics AX.

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

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

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

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

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

Interactive discovery session

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

Clear achievable objectives

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

Product capable of achieving objectives

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

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

Milestones

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

Costs in writing upfront

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

Change management plan

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

Administrative training

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

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

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

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

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

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

Everything needs a lifecycle.

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

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

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

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

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

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

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

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

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

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

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