All-In-One Identity Management and Cloud Security

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.

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.