All-In-One Identity Management and Cloud Security

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.

Active Directory password management is a three part problem: self service password reset;  password synchronization to other applications; and to eliminate passwords entirely!!!!

The first two are part of password management, but the third is the trend for forward looking IT organizations.  Let's talk about self service password reset and synchronization first and then talk about how to eliminate passwords completely.

Most users start the day with their Active Directory password.  And most users will eventually forget that password or get locked out.  To delegate the reset and unlocking, you need to have a way to verify (authenticate) who that user is before letting them change the password.  There are a few ways to do this:

• the traditional knowledge based question and answer
• second factor authentication -- not something they know but something they have like a mobile phone or software token
• help desk questions

The key to making self service password reset work is to force users to enroll.  EmpowerID builds an enrollment check into each authentication workflow; if the user is not enrolled, they will be re-directed to an enrollment form, keeping your password management system from becoming shelfware.

Second factor authentication likewise should have choices, either using EmpowerID's built in OATH tokens, sending a PIN to an SMS gateway, or accepting a hardware token.  Adding this on top of the knowledge based questions helps ensure that your user is who they say they are.

Users will still forget their own knowledge based answers or have a phone battery die so you need a help desk backup.  EmpowerID does not let the help desk see the knowledge based questions and answers so we provide a set that is visible to the help desk to aid in verifying the user's identity.  Once verified, the help desk can easily reset or unlock the account.

For most password management solutions, this is as far as it extends: Active Directory.  Since EmpowerID is a full IAM platform with connectors into almost any cloud or on-premise application, passwords can be synchronized to those applications.  For example, if a user has an AD account, a Google apps account, and three line of business accounts, EmpowerID can synchronize that password from AD upon reset and ensure that the user has a single cohesive password meeting all of the password complexity rules.  This is extremely valuable for your end users.

But why stop there.  Single sign on can eliminate the need to even have all of those passwords.  If your applications can be federated with SAML or OAuth or any other federation standard, EmpowerID can authenticate your user with their AD credentials, then pass a token to the application to authenticate them there without your user ever using or needing to know that other password.  If the applicaiton isn't federated, EmpowerID also offers Web Access Management (WAM), secure password vaulting, and a built-in virtual directory for authentication.

Eliminating the need for all of these passwords is definitely preferable and adds security.  With EmpowerID you can also have role based or resource based step up authentication, requiring a second factor for more secure assets.  Users don't know their passwords so deprovisioning is more thorough with fewer moving parts.

EmpowerID is a single code base, purpose built Identity & Access Management platform that performs all of these functions seamlessly and interoperably.  Don't fall into a trap of buying a password management software that doesn't do everything you need it to.  Take a look at EmpowerID and see how you can solve all of the password challenges.

Identity & Access Management (IAM) is a big undertaking.  I always joke that the successor to the CIO who purchases a legacy IAM platform is the one that gets all of the credit for the project.  But it doesn't have to be that way; an IAM platform that is easy to install, customize and configure AND that is modular can give ROI along the way.

A partner of ours calls that Think Big, Start Smart.

Take a look at the way EmpowerID segments an IAM project:

Some of these functions can be done standalone, some have a faster ROI than others, some have business owners that can fund the project.  But you have to choose a platform that first off can accomplish all of them and second off doesn't force you to buy all of it if you want to "start smart".

A great example of this is a customer who started by managing users and their access within SharePoint using EmpowerID's built-in claims functionality.  We were able to define a whole slew of dynamic roles and assign those to different SharePoint sites.  Once they had this functionality done, the roles and HR inventorying processes were already defined so a VERY easy next step was role based provisioning into all of the applicable systems.  Once accounts are defined, why not add single sign-on into those applications. 

This project was broken into three phases, all of the platform functionality was installed during the first phase (metadirectory, GRC functions, RBAC engine, visual workflow studio) and the customer just needed to purchase the appropriate module to unlock the functionality for each phase.  They were able to accomplish their main initial goal and future proof for the rest of their IAM needs.

EmpowerID's single code-base platform is what makes this work; we ship with over 400 out of the box workflow templates and all of the capabilities of the metadirectory, RBAC engine, audit/SOD capabilities and visual workflow studio.  This is out of the box regardless of the module.

The sections in green below are the functions that come with the platform:

When you are choosing a platform for IAM, think of these factors.  Can you start smart, get an initial positive ROI, and future proof for future needs?  IAM is big, never forget to think big.  And that means thinking EmpowerID.  Schedule a demo today!

Microsoft makes Office 365 pretty easy when you are already managing Active Directory with its DirSync utility.  However, this doesn't always work if your users are not in AD or if you have multiple forests.  So, how do you manage provisioning, group management and SSO to Office 365 without AD?

EmpowerID.

Let's take the first use case, users that are not in AD but that need an O365 account.  This happens often in franchises, education, manufacturing or when offering accounts to non-employees.  EmpowerID's metadirectory stores a "person" object that is completely independent of AD, this user account can then be provisioned to O365 and updated through EmpowerID's HTML5 user interface.

Users have the ability to manage group membership, passwords (including self service password reset) and single sign-on to O365 with the EmpowerID credentials.  All of these changes are made in the metadirectory which is synchronized directly to Office 365 without AD in between as well as direct Identity Administration where the workflows make live changes directly to Office 365 like we do to AD. Not all has to go through sync like FIM.

You can automate all of the provisioning/deprovisioning to the metadirectory based on a connector to any other system (student database for example).  The EmpowerID Office 365 connector does all of the heavy lifting that DirSync does but adds the complete workflow and RBAC capability of EmpowerID.  Without AD in the mix.

The other use case is one that a few customers have brought to us: Office 365 does not work with multiple AD forests unless you want to deal with FIM and the army of consultants / developers necessary to manage that.  Again, the EmpowerID metadirectory solves this, easily connecting and synchronizing each AD forest into the metadirectory, creating a person object that joins user accounts in each forest.

The EmpowerID Office 365 connector then does all of the heavy lifting, provisioning accounts, offering password management, single sign-on and group management.  Any changes you make can flow out to each AD forest as well.

The customers that have come to us for this scenario always point out the obvious, if they used FIM they are not future proofed, not only do they pay more for the initial deployment, but if there is another acquisition and another forest added, they have to start the whole process again with FIM.  With EmpowerID, it is a matter of connecting another AD forest with the connector already in place.  Easy peasy.

Office 365 is a great product (we use it internally) but there are limitations to deploying it with DirSync and some very specific use cases where it doesn't work.  EmpowerID fixes those use cases while giving a huge number of other IAM platform advantages.  Take the time for a demo of how we can manage O365 without AD and see how much more you can do with a robust single codebase IAM platform.

Single sign-on does not exist in a vacuum.  Especially in an extranet environment, you need to know who those users are, what access they should have, and give them a way to manage their identity.  Essentially, identity management cannot be separated from SSO.

When SSO projects come our way, the initial conversations are always around SAML federation, Web Access Management (WAM), or password vaulting.  We talk about identity providers, service providers, SharePoint claims, and multi-factor authentication.  Customers talk about their applications and user experience in SSO.  What they don't bring up is how to manage those external users because other SSO vendors avoid that conversation like the plague.

If all applications were federated (they aren't), then this might not be as big of a deal but in truth, most of our customers have a mix of SSO technologies and you need to know who those users are.  You will need to have self-registration for external users, automated provisioning for internal users, self service password reset for IdP credentials, attestation and certification of user accounts and access, and step up authentication for secure access.

EmpowerID's platform comes with base functionality for all of its modules.  The base platform contains the metadirectory, RBAC engine, and visual workflow studio.  All identity management workflows (create user, change password, etc) are part of the platform to manage the external user.  Your users will have all of the abilities for SSO and you will know who they are and have extensive identity management capabilities.

But, remember, the customer is coming to us for SSO so the platform still needs to be able to offer single sign-on in the most comprehensive way.  Many applications are federated (SAML, OAuth, OpenID, WS-Trust and WS-Federation) but for those that aren't the SSO platform needs to have multiple ways to handle that application.

SSO Manager offers a few options:

• Web Access Management (WAM): either using reverse proxy or an agent, SSO Manager can intercept access attempts to an application, send them over to EmpowerID for authentication and return them authenticated to the application without any interaction on their part
• Federated SSO: EmpowerID can act as either the identity provider or service provider using any federated protocol (SAML, OAuth, OpenID, WS-Trust, WS-Federation)
• Password vaulting: as a last resort, users can claim accounts, provide the username and password which will be vaulted securely on the EmpowerID server and provide the same seamless SSO experience for the user
• Shared accounts: for many applications such as Twitter or Facebook, corporate accounts need to be shared without giving out the password, the owner can share the account and revoke access when needed
• Virtual Directory: the EmpowerID metadirectory is exposed as a virtual LDAP directory that can be used as the back end identity store for any application

By offering this comprehensive solution, your users will authenticate and be presented with a dashboard of SSO applications; they don't need to know how you got them the SSO access, it is seamless.  You can manage their access and user accounts all from one platform, on a single code base with the easiest and most efficient management in the industry. 

Let us demonstrate these capabilities and you will see why the comprehensive platform is your best method to providing single sign-on.

Whether you are building a new application or trying to retire the old legacy directory for an old application, having a virtual directory directly tied to your identity directory gives you great flexibility.

EmpowerID maintains a metadirectory that inventories and updates all of your various identity stores on a continuous basis, keeping a single unified "person view" of each user, whether they be internal or external.  This metadirectory can be used for a lot more than Identity and Access Management (IAM), however.

But rather than synchronize all of this identity information to yet another directory, EmpowerID's Virtual Directory allows you to present this metadirectory identity information as LDAP.  EmpowerID roles are presented as LDAP groups and you can maintain the exact schema required for the application without having to manage another directory.

This virtual directory is especially useful for applications that require internal and external users to both have access, replacing the need to have external users inside of your corporate directory.  As LDAP, users on any OS can access, authenticate and authorize against the directory.

By using this virtual directory as your application directory, you no longer have to worry about separate provisioning and de-provisioning as all of the workflows around user management are included in your IAM, you simply create a role based provisioning workflow to create accounts in the virtual directory based on user attributes.  You can offer self registration, password management, single sign-on, and RBAC policies to apply to what your user can and cannot do in the application.

Since all of EmpowerID is workflow based and can be managed with APIs and web services, you can even build the management of these users into your application, lessening the learning curve for administration of the application

Virtual directories that are separate from your IAM have many of the same challenges as legacy directories, take a look at what you would need to integrate the two and take advantage of all of the IAM capabilities for your application.

Single sign-on does not have a magic bullet; instead, it requires a swiss army knife.  Meaning many different ways to get users authenticated into an application using only one set of credentials.  A German partner of ours calls this eierlegende Wollmilchsau based on one of our customers describing everything that EmpowerID can do.

This ability to perform multiple methods of single sign-on from federation to Web Access Management to password vaulting gives an extraordinary ability to get users authenticated to almost ANY web application using either corporate or social credentials.  EmpowerID lets you authenticate external or internal users, apply a role to them, giving them appropriate access to any resource (on premise or cloud) and, just as importantly, not force you to have AD credentials for the user.

This is where the comparison to Active Directory Federation Services (ADFS) comes in.  Not all of your users should be in AD and they are not always accessing WS* or SAML applications.  In addition, you need to have role based access control (RBAC) determining the level of access for the user.  And you need two factor authentication (TFA) for either highly privileged users or highly secure applications.  ADFS is just too limited.

The below list illustrates some of the advantages of a true SSO/Federation/WAM application like EmpowerID has over ADFS:

1. Directory neutral federation (AD, LDAP, SQL, CUSTOM, etc. etc.)

2. Multifactor authentication (including Smartcard, OATH and identity proofing)

3. Extensive list of out-of-box authentication providers (including AD, Username/Pwd, social credentials like Salesforce, Twitter etc. etc.)

4. Powerful claims generation, transformation and issuing (leverage full power of C#, Web Services)

5. Leverage RBAC and powerful Metadirectory to issue advanced claims (Business Role and Location, Management Roles, Set Groups etc. etc.)

6. Enhanced security for sensitive data with advanced claims level encryption

7. SSO for non-Microsoft applications

8. Complete support for OAuth 2.0

9. Complete support for SAML 2.0 SSO Web Profiles

10. SSO Application Dashboard + powerful features like Persona etc. etc.

There is really no comparison to having a complete eierlegende wollmilchsau swiss army knife SSO platform that can authenticate any of your users, using any credential, performing full RBAC, and connecting to any application on any network.  ADFS just cannot compare.

Imagine having your users empty their pockets at a big security checkpoint as they enter your building.  What kinds of devices would you find?  Tons of tablets, scads of smartphones, the rare Google Glass, and probably one guy who still has a pager.  Make a stack of all of these and it's most likely taller than your building.

This BYOD trend can obviously be a security risk but it is also an identity management opportunity.  The reason is that mobile devices are an integral part of a user's identity; users are very rarely separated from their phone so you can use the device to help identify them.

The best and most immediate use is two factor authentication (TFA).  Software based tokens are free, the OATH server comes with EmpowerID and the client apps (such as Google Authenticator) are free.  The uses for two factor authentication are many and can help balance the security risk that you're facing just allowing these devices.  We recommend three main uses for two factor authentication:

1. Two factor authentication with ALL password resets.  If a user is resetting their passwords, force TFA to ensure they are who they say they are.
2. Step up authentication.  When a user is attempting to access a highly secure resource (folder with 10Q financial documents, the SharePoint site with Coca Cola's secret recipe, etc.) step up their authentication to include two factor authentiation.
3. Role based authentication.  If a user wants to be highly privileged, make them prove who they are when they authenticate.  Often the users with the most privilege have the most clout in the organization and get away with the least security (CxO, domain admins, etc).  That is bad security.

On top of TFA, use your identity management platform for device registration.  If a user is authenticating and accessing resources from a mobile device, know who that user is and what device they are using.  Link the device to the user and have the tools to audit how and when the user is accessing company resources.

And, finally, have a self service portal that users can use from their mobile device.  EmpowerID has an HTML5 interface that works natively on all devices, allowing users to authenticate, reset their passwords, access SharePoint, request access to resources and all other identity actions.

These devices are not going away, take advantage of them in your identity management plans.  We can demo how EmpowerID can make that stack of phones work to your advantage, contact us today to see how!

SharePoint permissions do not have to be managed with SharePoint groups, those lonely unmanaged completely removed from the rest of the enterprise collections of users.  SharePoint has evolved to first accept Active Directory groups for permissions and now to accept roles via a claims provider.

Claims providers created in SharePoint can be used for adding claims to the security tokens of users when configuring permissions on secure objects like lists, sites, items and documents.  When EmpowerID is the claims provider, it provides its dynamic polyarchical roles as a selection in the SharePoint People Picker.

How is this useful?  Well, it's a lot easier to manage EmpowerID role memberships than SharePoint or even AD groups.  EmpowerID roles can be managed dynamically by any attribute in any connected identity store (Active Directory, HR, CRM, ERP).  Role locations as well can be mapped from any connected application so a user in the London OU in Active Directory will be mapped to the London role automatically.

By having management roles (the user's job(s)) and location in separate trees, you can define permissions very granularly.  For example, you may only want IT managers in London to have access to the SharePoint site to review IT tasks in London.  You simply pick from the two trees to get IT Admins in London.

You can even add a runtime decision by incorporating Attribute Based Access Control (ABAC) into the equation if you want to check your timecard system to only allow on-duty IT Admins to have access!

The advantage to all of this is that user's permissions are not static.  Conservative estimates say that internal turnover is about 20% per year, meaning that 1 in 5 users will change jobs.  Think of the last time you updated a SharePoint group....it is certainly not that often.  Roles, however, are dynamic, reading from attributes that flow from within HR or any other authoritative source.  If that IT Admin makes the mistake of starting in sales, she will automatically have her IT admin role revoked and new sales role(s) invoked.  Permissions will change without IT having to lift a finger.

Check out our whitepaper on dynamic roles or schedule a demonstration of EmpowerID and see how it can increase your security in SharePoint without having to mess around with SharePoint groups!