All-In-One Identity Management and Cloud Security

The average user in a medium to large enterprise has 16 applications that they need to access to do their job.  This means 16 username / password combinations.  Doing the math, this translates to a metric boatload of help desk calls to support this many passwords.

There are three things you can do about this:

1. Provide single sign on (SSO)
2. Provide self service password reset
3. Synchronize passwords between the applications

There are advantages and limitations to each option.  Single sign on is probably the best solution, having your users log in once and then be authenticated into each application.  However, if the application doesn't support federation, you will need to do password vaulting and you still have the problem of a lot of passwords.  Many legacy systems will have this limitation.

Providing self service password reset is also a great option.  It allows you to delegate changing passwords once forgotten and can have built in security like two factor authentication or forced enrollment.  But, you're supporting 16 applications and you might as well fix the problem before the horse leaves the barn.

That brings us to password synchronization.  You will give your user a single password that is the same for each application.  When they change it in one place (for example, Active Directory), it will be synchronized to each application.  Users will still need to enter a password each time, but they only have to remember 1 not 16.

Before I go any further, the same EmpowerID module for password synchronization also provides self service password reset, giving you option 2 & 3 in one fell swoop.  Since EmpowerID is a single code-base platform, EmpowerID SSO Manager also can work in conjunction with Password Manager to provide all three options to work together.

EmpowerID is a hub and spoke model, with a metadirectory sitting squarely in the middle keeping identity data and passwords synchronized.  You will most likely have a source of truth for the password, whether it be the EmpowerID directory or Active Directory.  Once this password is changed, EmpowerID will write out that password to all affected applications using stored procedures or APIs. 

If there are different password complexity requirements, EmpowerID can enforce the most restrictive and ensure that the user has a single password for all applications.  If there are mutually exclusive password policies (no special characters in one but special characters required in another, we should explore single sign on).

The first question is usually, what starts this process?  How can you synchronize a password if it is encrypted in the source of truth directory?  We can't, nobody can.  We need to force the synchronization process to start by changing the password initially.  Once EmpowerID has the password, we can follow the security guidelines of each application to synchronize the new password to these 16 applications.

The simplest way to do this is to force the user to change their password on the next login, whether it is to EmpowerID or to Active Directory.  This setting is easy to turn on and gives the user an easy way to create the new synchronized password.  We can also build the password change action into any authentication workflow or give them the requirement to change the password x days before expiration.

But we haven't really saved IT a lot of time yet unless it's easy to implement and configure.  That's where EmpowerID's visual workflow comes in.  Every identity action your users take goes through a workflow which can be customized and personalized.  For our password example, this means that for users with more highly privileged access can be forced to change passwords more often or to also need two factor authentication with OATH tokens. 

This workflow maps to your business process and gives you flexibility in how you manage your passwords and users, giving different policies for different roles or applications.  In short, it makes password management flexible.

But once the users have a single password, the metric boatload of time saved by IT can go towards the single sign on (SSO) project you've been looking at. 

Prior to The Dot Net Factory, I spent over six years helping healthcare organizations implement software solutions.  During that time I helped doctors, frontline care workers, financial staff, even maintence staff to replace paper documentation systems with electronic documentation solutions.  Now my time in Identity & Access Management (IAM) has helped me to bridge the gap between healthcare and IAM.  Here is a list of common complaints that I heard in the healthcare world:

• Why do I need another system to log into or remember a password?
• Who will setup the permissions for the solution – with HIPAA requirements they must be accurate and up to date?
• What if I am locked out and I need access now?

Another Password or Another Sign in!

As a healthcare professional your job first and foremost is to care for your patients, individuals, & residents.  This means that making sure that Sally gets her medications is your first priority but unfortunately if it doesn’t get documented then it didn’t happen which can setup you up for a costly error that can mean legal or survey errors in the future.  Then what if you need to check her blood pressure before giving the medications and that needs to be input to a vital system?  Now we have two systems that need to be accessed to input one interaction with a patient. 

Enter – SSO (single sign on), now staff can log into Windows, an EHR, or any other trusted app once and then EmpowerID handles the heavy lifting of making sure everyone get access to all of the apps you need without logging in again.

Providing the Right Access

You are a complicated healthcare entity.  You may have a doctor’s office, skilled nursing homes, a hospital, or you provide home healthcare.  You could also be one entity with several wings or units.  Your staff needs access to only what they need and nothing more in every system to avoid HIPPA concerns. 

EmpowerID's Role Based Access Control (RBAC) engine can pull from your HR system to assign the right access to the right people because we know that Sally is a Nurse Supervisor on the Alzheimer’s unit.  Those two things tell us who she manages, what she controls, and what she needs access to.  Your healthcare apps already filter by service location or healthcare unit.  Wouldn’t it be nice to have EmpowerID put them into the correct place at the correct time? 

Access Now!

Your patient is complaining of extreme pain and we must move him from outpatient service to the emergency room, now!  You are ready to take him but you know his daughter was in just earlier today and she needs to be contacted. You need to access your patient’s emergency contact information to see his daughter’s contact information and right as you go to access it you realize that you ignored your email that said your password would expire about 10 minutes ago (of all the moments). 

This particular app doesn’t support self-service password reset  so you have to submit a ticket or call the help desk to get access.  Or even worse you know a friends password or you can have your friend access the information for you (even though it is your patient and not his!).  With EmpowerID’s Password Manager we can give you the tools to reset the password on the fly.  And if you reset your password once it will push the change to all of your apps.  You will answer a series of questions that only you know the answer to; the best part is that EmpowerID can force you to enroll in the password reset system..  This ensures that when you are in this bind you are setup to take care of it quickly. 

These are only a few scenarios but Healthcare systems require so much complicated access and are used so frequently and with so much urgency that access has to be easy on your workers.  Anything from clocking in through one app to giving patients access to their health record from another app or accessing a client’s medication allergies makes things more of a challenge.  That is why our full IAM suite allows you to address one issue or all of them through one platform.

For years I've been engaged in the debate over using SharePoint or Active Directory groups for SharePoint permissions.  There are pros and cons to each and I am pretty sure there is no perfect answer to which is better.  However, I am pretty sure that role based access control to SharePoint solves the issues with both types of groups.

Here's why: you don't get token bloat with roles, you can create dynamic roles, you can run self service workflows for users to join roles, you can delegate role membership management to users, and you can use the roles for almost any other identity action.

EmpowerID makes role based SharePoint permissions possible by being a SharePoint Claims Provider for SharePoint 2010.  As the identity provider for SharePoint, EmpowerID will pass a token that has all of a user's claims including both authentication and authorization.  This means a user is authenticated into your network and navigates to a SharePoint site; SharePoint will check with EmpowerID to see if that user exists and what access she has.

Using WS-Federation, EmpowerID's Secure Token Service sends a token to SharePoint to authenticate that user.  In addition, any additional authorization claims are embedded into the token so that the user has access to all of the sites that she should.

As the claims provider for SharePoint, EmpowerID's roles are inserted into the people picker for site owners to provide access.  They see these roles right next to users and groups.  If an end user wants access to a site, they can request access and EmpowerID can assign them to a role (depending on approval levels of course).

That's how it works but the magic is in defining the roles for the user.  EmpowerID roles can be managed dynamically or delegated.  The majority of roles are going to be based on our polyarchical system and dynamic.  If you are in XYZ department in ABC location, you are in the XYZ role, the ABC role, and consequently the XYZ-ABC role.  This keeps the number of roles from getting bloated, having to create one for each management role/location combination.  These management roles can be based on any criteria: business unit, department, title, whatever fits your business.

Users can also request role membership.  The EmpowerID workflows to make this happen can require varying levels of approvals based on who is requesting and what they are requesting.  Some are automatic (book club member) some are severely restricted (earnings committee).  The self service interface can be via EmpowerID or exposed in SharePoint.

Lastly, each role has an owner or owners who can manage the membership, either for approvals or to directly manipulate the membership of the role.  Any role membership can be attested to, can be made temporary, or can require approvals.

Back to the SharePoint site owner, she doesn't have to worry about the membership of the roles.  The three methods above of managing membership means that she just has to worry about which role should have access.  Remember SharePoint groups are static and require manual intervention.  AD groups' membership cannot be viewed in SharePoint so the site owner has no idea who she just granted access to.  Each of these concerns is addressed with an EmpowerID role.

SharePoint is an invaluable tool for your business but managing it from within IT is burdensome.  Too often, SharePoint is configured and accurate on day one and the permissions slowly deteriorate as site owners manage access manually.  Fix this for them.  Manage roles for your entire identity ecosystem and provide these roles to site owners to manage their site's access.

EmpowerID's standards based approach will give you SSO and role based SharePoint permissions.  It is easy to manage and even easier once you start delegating.  Your SharePoint implementation will become more robust and useful.  Schedule an EmpowerID demonstration and see for yourself how your life can be easier.

Security is not easy.  IT's goal is to find a way to increase security without adding complexity to the point where it reduces productivity.  It is a fine line and one that needs constant balancing.

Authentication is a key point on this security balance beam.  Password complexity, multi factor authentication, adaptive authentication, federation and single sign on are all considerations in how to deliver security without hindering productivity. 

Starting on one end of the spectrum (no security but easy for users) is a simple eight character password synchronized to all of your applications....that is not good.  On the other end of the spectrum you can have each application having a separate complex 16 character password with biometrics and identity proofing and an OATH token....your users will kill you.

I believe that targeted two factor authentication with single sign on is the answer.  Adaptive authentication is what makes this work.  Because EmpowerID is built on a visual business process oriented workflow platform, you can insert additional authentication options into any workflow based on either the role of the user authenticating or based on the application that the user is tying to access.

Examples of these two options are:

• Adaptive authentication based on the user's role: All users should be able to authenticate into the network with a password but more highly privileged users (domain admins or VPs of finance) should have a higher level of security.  These users will be placed into a role or group that requires a second authentication factor such as an OATH token.  (note: I find it very interesting that those with the highest level of access tend to be those who can control their authentication level such as CxOs or domain admins)
• Adaptive authentication based on application:  This option will result in much less resistance and one could argue is actually more secure.  When a user tries to access a more highly sensitive application or resource, the EmpowerID workflow will recognize the resource as security level X and apply a more stringent authentication method such as knowledge based questions or an OATH token.

The key to all of this is that the IAM platform must have workflows that can increase authentication levels based on either the user's role or the resource's security level.  EmpowerID's visual workflow can even make a hybrid model of this where certain roles accessing certain resources can trigger the advanced authentication.

It is also crucial to use the correct second factor.  As you know, the first factor is what you know and the second factor is what you have and the third factor is what you are.  Remember that balancing act between security and productivity?  The productivity side also incorporates how hard it is to get the second factor into your users' hands.

How hard is it to get iris scans or fingerprints for every user?  How hard is it to deploy smart cards for remote users when you have a 5% turnover per year?  How difficult is it to manage physical assets to manage the "what your users have" factor?

This is what makes smart phones so darned valuable.  Everyone has one.  The flip side to the BYOD revolution is the first three letters: users bring their own!  You can take advantage of this by having users register their devices as part of the authentication (yes, EmpowerID can do that for you).  Then either text a code or demand an OATH token as the second factor.

There are plenty of open source apps available (for example, this one for the iPhone) for the OATH client so you don't even have to deploy hardware.  EmpowerID has its own OATH server, creating a simple seamless way to incorporate an open standard such as OATH and the widely available smart phone from your users to create a very flexible adaptive authentication method using two factor authentication.

And you get to balance productivity and security by selectively applying this second factor to highly secure and confidential resources and highly privileged users.  Additional security without sacrificing productivity.  Schedule a demonstration of EmpowerID and see how we can make that a reality for you.

Identity and access management (IAM) is a big concept.  Google analytics tells me that there are 18,100 searches for this term each and every month.  Gartner's definition is that "IAM ensures the right people have the right access to the right resources at the right time, enabling the right business outcomes."  That is a big concept.

However, it is rare that an organization is trying to solve every single aspect of IAM in a single project.  Some do and EmpowerID can do it.  But most don't and they need a modular approach to solving the IAM problem. 

To break down Gartner's definition:

• The right people: user provisioning into the metadirectory and all applications
• The right access: attribute and role based access control
• The right resources: inventorying of protected resources whether they be applications or files or anything
• The right time: workflow that ensures that all actors (people, roles, resources) are updated at all times
• The right business outcome: a workflow model that corresponds to your actual business process

The best and easiest example is a client who comes to us looking to solve its user provisioning problem (the right people).  EmpowerID does this in its sleep (just kidding, EmpowerID doesn't sleep).  The EmpowerID metadirectory constantly inventories all connected applications and identity stores, updating information and flowing it between any directory or database that needs the information. 

A user is provisioned in HR, gets an EmpowerID person account which then creates application accounts based on the user's role.  As soon as that user is changed in any connected application, that identity information flows througout the identity stores associated with that user.  As their role changes, their permissions change and their access changes.  Once the user leaves the organization, the user is de-provisioned.

As you can see, this quickly leaks beyond the right people to the right access.  And the right resources.  Yet not all products can accomplish this from a single platform, much less one with a single code base.  EmpowerID can.  And we haven't even gotten into what comes next.

User provisioning is a very common use case.  Very common.  What happens next is also common, we ask, "what about single sign on?"  Invariably, the client says something along the lines that they are looking to solve that next fiscal year.  Then we say, "what about your extranet, do you want to manage external identities?"  Just as often the answer is something along the lines of another team has a concurrent project for that.

And this is where having an actual identity management platform comes into play.  EmpowerID can solve the current project's business dilemma and future proof for the additional business problems.  The integrated metadirectory, roles engine and visual workflow platform allow all of the modules to work idependently or in conjunction to solve additional problems.

In the first SSO example, once the users are provisioned and synchronized and you know your identities are accurate, it is simple to base the applications that they can access on the role of these users (remember, you already have that in place).  Just adding a few single sign on workflows opens up the possibility for adaptive authentication based on resource or role.

You can easily incorporate partners and customers into the fold for the second example.  EmpowerID is designed for multi-tenancy so you can even have different customers have different levels of access.  Your roles are in place for your end users so it's easy to give permissions to employees to manage the customer's access and identities.

All of it works together without the need to buy everything at the time of the original project.  One of our more recent customers, a large publishing house, took this exact approach.  Their initial aim was user provisioning and access governance.  Basically, get their own house in order.  The next step is the customer portal, giving end users and book stores role based access to online ordering and account management.  The third phase is getting internal user's access to this customer portal and all of the legacy systems.

Basically, they future proofed their Identity & Access Management on top of their initial project's requirements.  This is an important ability to check when deciding on something as big as your IAM vendor, it's a lot more than just synchronizing some attributes back and forth; it's matching your business processes (now and in the future) to your IAM workflows. 

Schedule a demonstration and see how we can map what you need to what we do and be prepared to think in the future when we ask you what's next.

Believe it or not, we federate every single day in the real world.  The whole concept of federation is that a "service provider" trusts the "identity provider".  In the case of federated single sign on in the enterprise, this means that Salesforce.com (the service provider) trusts Active Directory (the identity provider) and allows you access.

In the real world, the best example is your driver's license.  When you present your driver's license to the bank to prove that you are you, the bank (service provider) is trusting that the DMV (identity provider) has properly vetted you with birth certificates, social security cards, or other identity information.  Because of this trust, or federation, you don't have to carry all of these documents with you everywhere and prove to every single person that you are you.  They trust the DMV (or whatever institution in your country provides driver's licenses) to have taken the appropriate steps to prove your identity.

Don't get me wrong, IT systems are the real world.  And you just need a mechanism to trust your identity provider.  And something akin to a driver's license.  Thankfully, we have several standards that act as a driver's license: SAML, OAuth, OpenID, WS-Trust and WS-Federation. 

When a user authenticates into the service provider (in this case Salesforce.com), Salesforce.com asks for ID.  Since the application is federated with empowerID, the user doesn't have to pull out all of her identity documentation, she just needs the driver's license, in this case a SAML token.  Reaching into her wallet (actually the secure token server in empowerID), she pulls out her SAML token (actually, empowerID sends it to the service provider) and presents it as evidence that she is who she says she is and should have access to the application.

Since Salesforce.com trusts the identity provider and hence the SAML token, the user is authenticated and allowed in to the application.  No username and password (analagous to the mess of identity documents like birth certificates, etc) or difficulties in signing in.

There are other Federated Single Sign On Scenarios (this is scenario number 1, corporate login to cloud application).  But in each one, consider the SAML token (or other protocol) to be the driver's license.  Your user presents this token as identity proof to the bank teller or airline ticket representative or retail clerk and that person (service provider) trusts that you are who you say you are and lets you in.

Once you have this capability, it is easy to trust partners, customers, contractors, and other entities inside or outside of your organization and offer them single signon.  Imagine you are a book publisher who wants to sell books and offer other service options to consumers, authors and editors in an external portal. 

You won't get very far if you are forcing them to re-enter passwords and user names for each application.  Once you authenticate them once against empowerID (your identity provider), they are federated into every single one of those applications.  And the best part is that unlike the real world, they only have to reach into the secure token service once for that SAML token, it moves along with them presenting itself every time they hit a federated application.

Take a look at our whitepaper and see if any of these scenarios apply to you and let's make federated single sign on a real world solution for you.  Click the button below to download your copy of the whitepaper.

To paraphrase Gartner, Identity and Access Management is the act of getting the right people the right access to the right resources at the right time.  Central to that concept is the right people.

Think of the people that you have: employees, contractors, customers, and prospects.  Each of those users needs access to certain resources on your network and you certainly don't want to treat them all the same.  You need role based provisioning to ensure that each user gets provisioned to the appropriate applications.

As an example, your employees will need user accounts in Exchange, SharePoint, CRM, ERP, Google Apps, etc.  Contractors will need a subset of that with more limited roles.  Customers will need accounts in the supply chain software, ticket management, and maybe SharePoint.  Prospect you just want to make sure that they are in CRM and have access to general sites within SharePoint.

So how do you automate this?

For each type of user you will need an authoritative source, the Identity Store of Truth.  For employees and contractors, it most likely will be your HRIS.  For customers, it can be the billing system or CRM.  For prospects, you might want to have a self-registration page.  Each of these Identity Stores of Truth will connect to the empowerID metadirectory, creating a person object that defines roles based on what data store they come from and attributes that we know about them (department, total annual billing, location, etc).  These roles are handled dynamically and change as a user's status changes.

Based on these roles, empowerID will provision user accounts into each of the connected systems listed above.  The metadirectory will then have a joined record of each user's accounts and can synchronize any changes from authoritative sources over to the connected system.

This pertains to the ongoing lifecycle of each of these users.  As you know, users are not static, they change jobs, they move from contractor to employee, prospect to customer and their needs change.  So, provisioning has to keep going to keep up with these users' lifecycles.  This is a key part of the concept of the right person having the right access at the right time.

EmpowerID's metadirectory is constantly inventorying each of these connected systems, if it sees a change to a contractor in the HRIS, it flows that to each application, possibly provisioning or deprovisioning accounts, and most likely changing their roles in all of these systems.

And it is all handled by a visual IAM workflow.  You have probably designed this process on a whiteboard or in Visio.  EmpowerID's workflow emulates this look and feel, allowing you to map the process to your IAM process.  And, the beauty of it?  It is true automated provisioning.  Not just once but every time a change happens.

Once you have your user provisioning automated, empowerID opens up the world of RBAC and federation and password management and governance and auditing.  But start with the "right people" through automated user provisioning and you've won the first and most important battle. 

Schedule a demo now and see how it works!

As reported at ABC News, "early this morning it was found that Skype's password reset tool had been compromised. Discovered by Russian hackers and first reported by the tech site the Next Web, all that was needed to get into a Skype account was a Skype user name and the associated email address. The typical security roadblocks between getting into an account weren't in place; it didn't ask a user to confirm an email address with an email or answer a security question."

Even these steps aren't as secure as they could be.  Self service password reset rides that delicate balance between productivity and security.  Users will forget passwords and get locked out, to minimize the disruption to their work day, you need to offer self service with as few roadblocks as possible.  However, the bad guys can take advantage of this lack of roadblocks and reset passwords. 

You need to know that the person resetting the password is who they say they are.

As far as I can tell in Skype's case, it wasn't really that they didn't have the technology in place, it was that they went too far towards the productivity scale in specific use cases.  Or they had a technical issue, I'm not a reporter, I don't know.

But there is something you can learn from this.  Let's start with the idea of tipping the scale all the way to security while still living in the world or self service (as opposed to making someone show up at the help desk and do an iris scan).

What can you do to ensure that user is who they say they are?

• Knowledge based questions.  This is the concept of "what you know."  The user's eye color, first make of car, favorite pasta, etc.  On its own, this is completely guessable by looking at pictures in the cube or a FaceBook profile.
• Two factor authentication.  This is the concept of "what you have."  When the user attempts to reset their password, send them a text or have them use an OATH token or take a biometric fingerprint scan.  This piece, in addition to "what you know", is the most important step.
• Periodic forced re-enrollment.  If you can force enrollment in the self service password reset program periodically, the user will remember their questions, update with their new cell phone number, and confirm their identity.
• Identity proofing.  There are two ways to do this.  You know a lot about your users (think of all of your identity stores), make them answer something that you know about them that a hacker might not like their date of hire, amount of last commission check, boss's favorite ice cream.  If you don't have that information, you can utilize services such as Equifax' identity proofing where they will answer the amount of their mortgage or some other information.
• Multiple account management.  Active Directory self service password reset is the key one here but if a system like empowerID can manage passwords in multiple accounts and add password complexity on top of your domain policy, then do it.

If you set these steps as your default policy, you will have gone overboard and tipped the scale too far towards security and have a mob of angry pitchfork wielding users on your hands.  So you have to temper it slightly.

If you are using empowerID for this (and I assume you are because I'm pretty sure nobody else can force enrollment like we can!), you also have roles for your users and security levels for your applications.  You can integrate these factors into your self service password reset program by incorporating any of these features on an as-needed basis.

For example, turn off identity proofing and biometrics unless a user is trying to reset their password for a high security system like the financials database.  If the user's role is sales, resetting their salesforce.com account should involve two factor authentication but should not require it for thei quotation system (assuming they need this right now!).

Mix and match security levels of the system and role of the user to determine how far you need to tip the scale.  If you have multiple factor authentication on the most secure systems, you might be able to dial down the requirements just to reset their Active Directory password.

Many of these features are exclusive to empowerID.  For sure, the integration of password management with other identity and access management features is unique to empowerID.  See how to take advantage of these best practices in self service password reset with a personalized demo today.

Adaptive authentication conjures up images of complexity.  Turning over your identities to HAL 9000 or something equally scary.  But, in reality, it can be simpler than that.  Remember the goal of identity and access management per Gartner is to ensure that "the right people get the right access to the right resources at the right time, enabling the right business outcomes."

Part of compliance to that principle is knowing who the right people are and what the right resources are.  So, let's break out the actors in this adaptive authentication scenario into 2 people and 2 resources.  Then it's simple to determine what the right access is.

People (or roles):  1) marketing manager and 2) finance director.

Resources: 1) salesforce.com, 2) folder containing 10K documents, and 3) internal SharePoint portal.

Each user will dynamically belong to a role based on their title, department and location for example.  In this case, we will consider these users as roles.

Both roles need access to Salesforce.com.  It is considered a security level 2 application when being accessed by any role outside of sales and requires a second factor authentication when accessing.

Only the finance director needs access to the 10K documents but since these are highly secure level 3 security resources, not only is a second factor authentication is needed, but a notification needs to be sent to the CFO every time someone accesses the documents.

And both roles need access to SharePoint; no adaptive authentication needed.

This is what makes adaptive authentication possible.  The empowerID directory is actually an identity provider and users authenticate against it.  Since it supports federation, it will use your Windows authentication, but still be managing all of your application and resource access.

So, in the first scenario, when the two users try to access salesforce.com; empowerID will see that their roles are not in sales and force a second factor authentication before authenticating them to salesforce.com.

The same thing happens when each user tries to access the financial documents in the 10K folder.  empowerID stops the marketing manager dead in his tracks since he doesn't have access to that resource.  When the finance director accesses the folder, empowerID enforces the second factor authentication and sends a notification to the CFO.  In this instance, you could also do identity proofing, have a workflow approval, or even grant only temporary access.

The same two users go to SharePoint and both are already authenticated.  Of course, once in SharePoint, the users have different experiences based on their roles in empowerID, but we aren't forcing any extra authentication here.

Adaptive authentication is a fairly straight forward concept that doesn't have to be any more complicated than what we described above.  You set security levels on your resources (as granular as you would like); you create roles for your users.  Certain roles have more stringent authentication requirements for certain security level resources. 

You are able to improve security without forcing these more strict security measures on every single role and resource.

Cloud provisioning and single sign on go hand in hand.  IT wants only the right users to have the right access to cloud applications.  Users want that access and to not be bothered having to re-authenticate (well, actually, they say things like "why should I have to enter another password" in a nasally voice usually).

The problem is that the Identity Management industry evolved from the on-premise world and is stuck in its own tracks.  Most vendors' provisioning solutions were either developed separately from their single sign-on solutions or just don't exist in one platform.  Most of the federated single sign-on vendors don't even have a provisioning solution.

So how do you get that perfect world of a user being provisioned into a cloud application based on their role (or something you know about them), getting the correct application role, and federating to keep the number of passwords down for your users?  And, to top that off, keep your security team happy by de-provisioning that user when their job changes?

You don't do it with cloud vendors or traditional IAM solutions.  EmpowerID's tagline is a "New breed of Identity Management" and this is why.  The platform was built from the ground up without the burdens of acquisitions or partnerships to create the full suite.  So, the whole product line shares the same RBAC model, the same API layer, the same metadirectory, the same visual workflow designer.  It is a true platform.

What that does for you is allow you to have the same workflow for role based provisioning for both the cloud and on premise applications.  Map your business roles to application roles and then apply those roles to role based authentication.  It means that if you provision a user in salesforce.com, you can federate using empowerID as the identity provider, giving the elusive single sign-on for that user.

And, you can get even more granular than that.  If the user is accessing highly secure resources, you can force two factor authentication only when the user tries to access that resource.  Picture this, your finance director logs in to Windows in the morning and checks her email and browses the internet to see what the markets are doing.  She clicks on the link to look at the accounts receivable report, empowerID sees that is considered highly secure, and sends a text code as a second factor authentication; she simply enters that code and is authenticated for all resources of that access level.  When she goes into salesforce.com to see the forecast, empowerID knows who she is and authenticates her automatically.

You have just increased security and ease for your user.

Now for the fun part.  Your finance director is looking at a commission report and realizes that she should be in sales.  She changes departments which is reflected in Peoplesoft.  EmpowerID inventories the HR system, changes her department and roles, which deprovisions her from access to the finance system and provisions her a new account in the cloud based marketing automation system.  She now has an account in the cloud application and single sign on to that app.

We have all been wanting the complete soup to nuts identity and access management system that handles all of this seamlessly.  The world got more complicated with cloud applications but having the new breed of identity management software allows you to provision to cloud applications, offer single sign on, and achieve your IAM goals.

Take 30 minutes for a personalized demonstration of empowerID and see how we can help you achieve all or some of these lofty goals.