All-In-One Identity Management and Cloud Security

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.

Identity & Access Management (IAM) is built on workflows -- a workflow is the sequence of actions that actually decide who a user is, what they can do, and to what can they do it.  I like Gartner's definition: "IAM ensures the right people get the right access to the right resources at the right time, enabling the right business outcomes."

All of those "right this" or "right that" is where it gets complicated.  Who can do what, how do you determine who has the rights to undertake a particular action in a workflow?  The RBAC model relies on roles (and ABAC to a lesser extent); based on what we know about a user's identity (department, title, location, business function, etc), we determine what their role is.  We then assign permissions to roles rather than to individual users.

Here's a great example: a doctor can access a patient's medical records.  Easy...we have two roles, doctor and patient.  Let's make it match the real world though, a doctor can only access a patient's medical records if that patient is under that doctor's care.  We can't make that many roles, so we add a run-time ABAC check to see if that particular patient is under that doctor's care and only grant access if that is true.  We do this with only two roles but use ABAC for finer granularity.  We have a whitepaper on the RBAC and ABAC hybrid model, please download it.

So, that's how we define who has access.  But more often than not, there is an approval layer in the workflow.  We know that an admin role can create a new user but might need an HR approval before it happens.  A user can update their own phone number but their manager needs to approve it.  A user can join a distribution list but the group owners need to approve it.  It's a simple business control but can get complex.

And that's where Rights Based Approval Routing (RBAR) comes in.  When designing the workflow around users joining groups, you can't define a single role as the approver because there are many (IT admins, the group owner, your COO for example).  What you do is put in a "go for approval" shape and let RBAR handle it.

The RBAR approval shape basically says, "does the user requesting access have the right to do this?"  If the answer is yes, then, bam, it's approved.  If the answer is no, RBAR asks, "well then who does?" and goes to get that approval.

Let's use our group example, the user requests to join the party planning committee distribution group.  RBAR notes that the user is not an owner or an admin so it first attempts to send an approval request to the owners.  If there are owners, that approval message is in their hands.  If there are no owners (you remember from The Office how often that committee changed), then RBAR looks up who else can do it...IT admins and the COO...and sends it to them for approval.

Without the IAM architect having to do any of the work for this multi-faceted approval methodology, RBAR has made a robust and easy method of implementing Role Based Access Control (RBAC) and getting more out of less resources.  Check out a more technical explanation of how RBAR fits into IAM workflow.

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

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

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

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

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

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

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