All-In-One Identity Management and Cloud Security

I often think of Gartner's quote on identity and access management: "the right people have access to the right systems at the right time" and think how do you know if they are the right people or the right systems or the right access?  We work with organizations with hundreds of thousands of users, does Bob in IT know all of them?

I'm being facetious of course, there's nobody in IT named Bob usually.  But that's where your identity and access management platform comes in.  It is busy giving people access to systems and you need to make sure that you are inserting the "right" into that sentence & process.

Having trusted authoritative sources really helps.  If you know that HR and other systems know all of the employees, contractors, partners and customers, you can usually cover the "right person" aspect of all of this.  But, that isn't always the case, so you have your first attestation option right there to solve the "right people" issue.

There will be a departmental owner or manager or HR person who can attest periodically that that user is still an active employee.  Build a workflow where somebody has to approve the continuing existence of that user account.  Not just a network account, but application accounts too.  Think of the savings if you periodically have users attest that they still need that cloud application account for which you are paying a monthly fee.

If the account hasn't been used or accessed for a certain period (say, 90 days), bump up the attestation.  It's easy to build this into a BPM-based identity workflow.  Make more secure application accounts have a higher degree of attestation involving identity proofing or two factor authentication.

So, with that user attestation process you solve the right systems and the right people but what about the right access?  Roles and group attestation helps solve this.  Have the role or group owner attest to the membership of the group and the group's rights and permissions on a quarterly or yearly basis.  Give them the audit reports to show what that role or group can do and who has been doing it.

This should all be built in to the identity workflows that come with your IAM platform, if not, take a look at EmpowerID.  Dont' just give access to people, give the right access to the right people.

End users know their stuff.  I know this isn't a common refrain in IT but if you're talking about the users themselves when saying "their stuff" then there is no dispute.  So for some identity information, you actually need the user.  And to offer identity management self service.

The most obvious and important identity store to consider is Active Directory.  There is a lot of identity information within there to delegate: mobile phone, home address, and other personal information.  This is the sort of identity information your company needs and can only be provided by the users themselves.  In fact, once they enter it via your self service interface, take advantage of this and flow the information back to the HR system.

The items above you can usually trust your end users to provide.  There are a few items where you want to have control, put some sort of approval workflow on it.  Take for example, business phone, maybe you aren't flowing this from your telecom database and want your end user to update it but want the telecom guys to approve it, shoot a workflow request to them before committing it to AD.  I can't stress this enough, self service liberates IT but you need to have controls in place.

AD groups are a common delegated item.  End users should be able to join and leave groups but not all of them.  Using rights based approval routing, you can set specific groups to require group owner or admin approval before joining.  In fact, some groups should be completely off limits to self service (think financial reporting).

But Active Directory isn't the only identity store in your organization.  The benefit to a full Identity and Access Management platform is that you aren't limited to just AD.  By having a metadirectory in the middle of everything, you can create self service forms to the metadirectory or directly to any connected application. 

A great example is when you need to apply for a specific role in salesforce or your jive community.  Having a self service option allows you to apply for the role, enforce an approval workflow and using the IAM workflows, set a time limit on the access (temporary privileged access).  As you can see, self service is not limited to Active Directory at all but it can be in the exact same self service interface.

Of course, don't forget that self service identity management has to be part of an identity ecosystem.  Any attributes, roles or information that your users provide through self service should flow back into your identity stores and any appropriate applications.

Let us take you on a tour of how you can make this identity ecosystem more diverse and robust through self service.  With control.

Users have a lot of accounts; it keeps both IT and users busy.  The trick is to give them the accounts that they need and only the accounts that they need.  Automated user provisioning is essential.

The "person" directory is the foundation of how automated provisioning should work.  A person account should be created for each user (full time employee, contractor, partner, customer, etc).  This person account should have enough information about it to start a chain of provisioning workflows that create a joined account for each application the user needs.  We call this role based provisioning.

Let's start with how to populate the "person" directory, or metadirectory.  The metadirectory will inventory an authoritative source (HRIS for employees, a spreadsheet for contractors {just kidding}, CRM for customers and partners) to check to see any new users and provision a person account with attributes flowing from that or any other system.

Dynamic roles are provisioned (assigned) based on those attributes.  Based on those roles, the user gets an AD account, a salesforce.com account, an SAP account, line of business app accounts, a Jive account, and whatever else their role and your imaginative workflow decides.  Role mapping determines the user's role in each of these systems.

This provisioning workflow is designed around your business rules and processes.  EmpowerID offers a visual workflow designer that has almost 400 out of the box templates and the power to customize each worfklow with 400 different actions or shapes.

The provisioning workflow is kicked off as soon as the metadirectory inventories the authoritative source and determines this is a new user.  The workflow will create the person and automate the user provisioning for the appropriate applications based on roles, creating mailboxes, updating appropriate group memberships and basically doing the work to make a user a productive employee.  This is automated user provisioning in a way that matches your business process.

Speaking of business processes, ever notice how there are some one off situations?  A user account needs to be provisioned through an alternate channel?  Opening up the applications (or ADUC) themselves is a security risk if you just have admins go in there with no means to audit access.  Using these same provisioning workflows, you can design a form, assign role based permissions and have an admin kick off the process through delegation.  It is auditable, access can be made temporary and when the metadirectory inventories the systems it will know from where this account originated.

In our years of experience with empowerID and automated user provisioning, we have seen that no two use cases are the same.  But the process almost always is.  With configuration (not customization), you can have your user provisioning process automated.

If you want to see how it's done, let's take an hour and demonstrate these use cases for you.  Schedule a demo now!

When you embark on an RBAC project, you have to consider that you already have roles in place.  Application roles, location roles, OUs, and security groups.  All of these have to be mapped to your management and organizational roles.

Let's start with mapping location roles to physical locations.  Your OUs are probably organized by location or geography.  Many of your RBAC permissions are based on location and you want to have a single parent role for each location with multiple OUs and directory locations mapping to the single location based role.

As you can see, you can map multiple external roles to a single empowerID role.  This allows you to manage more permissions and access with a single role in empowerID.

This concept becomes even more important with application roles.  A single sales manager role in empowerID can map to the salesforce.com role, the Exchange role, and the SharePoint role.  It takes you out of the business of managing roles and permissions in every single application on your network and cloud.

The benefit to you is that you can make the empowerID roles dynamic, have the user's roles change based on any attribute changes in Active Directory or any other connected system.  So that sales manager gets promoted to sales director and all of his/her roles change immediately.  Not only in empowerID but that streams all the way down to all of his/her application roles.

Take a look at our whitepaper on enterprise authorization and the RBAC / ABAC hybrid approach.  Or save yourself some wear on your reading glasses and arrange for a demonstration of role mapping for complete RBAC.

Highly privileged accounts can cause a lot of damage and do a lot of good.  There is a tricky balancing act between having IT users with too much privilege and not enough.  On one hand, do their job and on the other, perform mischief (such as accidentally delete an OU which is a real example).

I have seen extremes from one out of business retailer who let every user have access to Active Directory Users & Computers (ADUC) to minimize help desk calls to a very successful international bank who has pretty much shut down ADUC in favor of a granular rights based self service delegation through empowerID.

That second use case is the one I want to talk about.  Not just for ADUC but for all resources that you want to control access through RBAC (role based access control) or ABAC (attribute based access control).  One of my go-to sayings is: "what you can't automate, delegate."

Let's start with Active Directory.  IT needs to create accounts, groups, computers and other objects in AD.  The problem with AD and ADUC is that one size fits all.  The same user who can create a group can also create a user or delete an OU.  You have to shut that thing down. 

With a delegated Active Directory self service system, you can have specific roles have access to create, modify or delete only certain AD objects.  You can get granular enough that a user can even manage their direct reports or only certain attributes in their own profile.  And, you can put workflow approvals on any changes made depending on who made the request (rights based approval routing).

What about users wanting to join groups?  Same thing, create a form for users to request access to a group and send it through appropriate approvals.  Depending on the group or user requesting access, maybe even auto-approve it. 

Why even stop there?  Most users are joining groups to have access to a file or folder.  Use a self service page to request access to that resource and have empowerID map what group that user needs to be in.

But that's not the key here.  The key is that when privileged access to a role or group is requested, don't just give it for an eternity.  Temporary privileged access keeps that user from having permanent access to the role or resource.  Put a time limit on the user's privileged access.  Limit the exposure.

Other useful tools is to require multi-factor authentication (MFA) when the user attempts to use the access.  Before you allow it, require them to authenticate with an SMS text to a known device or identity proofing with something that only they will know.

The idea is that privileged access is needed for many users to do their job.  But give them this access only when they need it.  If they have it permanently, ensure it is really them by utilizing MFA upon usage.  Try to shut down any systems with all or nothing access and create an identity policy and system that gives users another more secure route to access.

And, lastly, track this stuff.  If you know when and for how long a user had privileged access and what user or policy granted this access, you have the audit trail to prove that you are keeping your corporate valuables safe and secure.

Take a look at our whitepaper on replacing ADUC and/or request a demonstration on how to reduce privileged access in your environment.

Getting a user provisioned and productive on your network is one thing, getting their cloud accounts sorted is a whole other ball of wax.  In the old days, you had Active Directory, Exchange, some line of business applications and ERP this and that.  Presto, boomo, you had a provisioned user.

Now if you want to automate the user account provisioning process, you need to account for any cloud applications the user has.  These cloud applications have different UIs, are owned by different lines of business and generally add a wrinkle to your identity and access management that you just don't need.

But it's the world we live in and we have to somehow manage cloud identities with our internal identities.  The three main things to worry about are: 1) provisioning / deprovisioning, 2) role based access control, and 3) federated single sign on.

Automating provisioning and deprovisioniong is the first and most important step.  You pay for these accounts monthly per user so if someone has left the company, you want that account gone immediately.  An IAM platform like empowerID will have connectors to all of your major cloud applications like Salesforce, Google apps or Hubspot.  For those without an out of the box connector, building one with the applications APIs is pretty easy. 

Unless your IAM solution can do role based provisioning, your user will always have this account though.  Remember that provisioning isn't a one time affair, it is a lifecycle for the user, make sure that your automated provisioning workflow (and deprovisioning) takes into account the user's role or attributes and deprovision the account if their role is no longer eligible for the application.

But provisioning these accounts is pointless if you still have to go into the application and manage the user manually.  Application level role based access control (RBAC) is built into most applications.  Most IAM platforms have enterprise level RBAC.  Role mapping is essential for cloud applications, map the enterprise roles to the application role during provisioning and as your user moves around the organization.  An example is Salesforce, if your user is promoted from sales executive to sales director, their enterprise role will change; a good IAM platform will then change their cloud application role along with it.

Last, but not least, is the federated single sign on.  Your users have increased their number of application passwords exponentially (that is a bit of an exaggeration), make sure that you are federating with your cloud applicaitons.  SAML and other standards have made this easy if your IAM platform supports it.  We have a whitepaper on the Top 5 Federated single sign on scenarios, take a look and see what matches your needs.

IT departments spent the better part of the last decade figuring out corporate identities.  Most IAM vendors built their "platforms" before the cloud became so prevalent.  EmpowerID was conceived and built from 2008 onwards with the cloud in mind the entire time.  It is a platform based on a single code base that allows you to manage the provisioning and deprovisioning of cloud accounts, their roles and access, and federation all within a single IAM platform.  You do the work once for all identities, whether it's internal or cloudy.

A demo of this complete ecosystem for your users' identities will show you how simple this can be to manage. 

At a back to school party this weekend, one of the parents asked what I did.  After I explained identity and access management, this parent sounded a familiar refrain, "why do I need so many passwords?"  After the perfunctory and admittedly glib, "because you don't use EmpowerID", I gave the real answer: because not everyone knows how simple it is.

Because it really is simple.  Federated single signon with SAML (Security Assertion Markup Language) is easy.  There are only three parties involved: the user, the service provider and the identity provider.  And IT controls both the service and identity providers (good luck with that user!).

I'm picking salesforce.com as an example because it is common.  Your user has an identity provider (in this case EmpowerID) which authenticates that user into the network.  They check their email and then get down to the business of making sales.  When they go to salesforce.com (the service provider), that user will be instantly redirected back to EmpowerID without them knowing.  EmpowerID knows they are authenticated and then sends a token to salesforce.com with that users credentials and the user is logged in to salesforce.com without them even knowing what happened.  They then make your company a lot of money.

The behind the scenes stuff isn't too much trickier.  You have to configure the identity provider (EmpowerID), the service provider (salesforce), and give the user the correct URL to log in.  We have a whole wiki article on configuring this federated single signon, but I'll summarize for the blog:

• create a Salesforce service provider in EmpowerID
• configure the SAML settings including:
  
  • Name and Display Name: These are the name and display names you supplied for the SSO Connection when you created it.
  • Issuer: This is the party issuing the SAML assertion attesting to the user's identity. The value here should be EmpowerID.
  • TargetIDP/SP URL:This is the URL for accessing your Salesforce.com account from EmpowerID. When first created, EmpowerID populates this field with the relative path to the SSO Service and Connection ID only. To complete the full path, concatenate this with the FQDN of the EmpowerID web server in your environment.
  • ACS URL: This is the URL to the Assertion Consumer Service for the application. The value here should be the base login for Salesforce.com.
  • Enable ACS SSO Connect Query String: This field should be deselected.
  • Login Workflow ACS URL: This is the URL to the EmpowerID Login workflow. This workflow verifies the identity and account ownership of any person logging in to EmpowerID.
  • Endpoint Binding: This specified the type of binding used for the SAML assertion. The value here should be "HTTPPost."
  • Authentication Request: Leave this field empty.
  • Format: This specifies the format of the assertion used to identity a user to the service provider, if any. The value here should be "Unspecified."
  • Account Store: This specifies the account store in which each EmpowerID is to place each registered account. When the SSO Connection is created, EmpowerID automatically creates the corresponding account store for the connection. When an EmpowerID Person claims and registers an account from the Corporate Salesforce SSO application, EmpowerID places their account in the Corporate Salesforce account store created for the application and links the account to that user's EmpowerID Person.
  • Login Tile Image URL: This points to the image that is used in EmpowerID as link for accessing the service provider.
  • Description: This is the description you supplied for the SSO Connection when you created it.
• Verify all of the settings

Configuring the service provider:

• From your web browser, log in to your Salesforce.com account as an adminstrator.
• In Salesforce, click on the Setup link at the top of the page, navigate to Security Controls > Single Sign-On Settings under Administration Setup and click Edit.
• Tick SAML Enabled to view the SAML sigle sign-on settings.
• Specify SAML 2.0 as the SAML version.
• Enter "EmpowerID" in the Issuer field.
• Browse for and upload the STS certificate used in your EmpowerID deployment.
• In the Identity Provider Login URL text field, enter the value of the Target IDP/SP URL for the Salesforce SP SSO Connection. This URL is used to access Salesforce.com accounts from EmpowerID.
• From the SAML User ID Type checkbox, select Assertion contains User's salesforce.com username.
• From the SAML User ID Location checkbox, select User ID is in the NameIdentifier element of the Subject statement.
• From the Entity Id checkbox, select https://saml.salesforce.com.
• Save your changes.

Configuring users:

Users logged into the EmpowerID Management Console can request that their Salesforce accounts be registered with EmpowerID by clicking on the tile. This sends the request to an approver. Once the request is approved, a tile for the Salesforce SSO Application is placed in the My SSO Applications pane, allowing users to seamlessly access their Salesforce.com accounts from EmpowerID.   That tile is in essence a URL, they can bookmark it, have it in the intranet or click from anywhere in the network for seamless federated single signon with Salesforce.

Once you have done this (and it is this easy with all SAML applications), you can solve that "I have too many passwords" problem and give me less to talk about at cocktail parties.

Check out our whitepaper on the top 5 federated single sign on scenarios or arrange for a demonstration of how EmpowerID can be your identity provider of choice!

Role based authentication is not RBAC.  RBAC determines what resource or application you can access based on your role while role based authentication determines how you will need to authenticate to access that resource or application.  In the way EmpowerID performs this function, it is more akin to adaptive authentication.

There is a key difference.  In adaptive authentication, EmpowerID determines your authentication method based on the security level of the resource or application.  For example, to access the main intranet page, you only need to authenticate with your username and password.  To access the employee benefits portal, you may need to authenticate with username and password but also add identity proofing (answer something only you will know).  To access the financials, you will need to perform multi-factor authentication such as enter a PIN that EmpowerID sends to a mobile device that you have registered.  Again, adaptive authentication is all about the security level of the resource or application you are accessing.

Role based authentication is all about you.  Who you are and what your role is determines the levels of authentication you will need to perform.  Back to examples, every employee role needs to enter username and password when authenticating.  Privileged roles such as domain admin or CFO might need to add additional authentication methods such as identity proofing or multi-factor authentication.  Any user who is a member of a role such as "on probation" might need to use multi-factor authentication with a company provided cell phone; using this method, the fastest way to deprovision their access is take away the cell phone, then go and deprovision their user accounts.

But neither of these methods exist in a vacuum.  The best practice would be to manage authorization with a hybrid of role based authentication and adaptive authentication.  Set the security levels on each resource and application and assign roles to each user.  Then develop the authentication workflow where it checks for combinations of role and resource security level to determine what additional levels of authentication are required.  It sounds complicated, but it is pretty simple if you know what resources need the best protection.

I have spent a lot of time lately thinking about passwords and how inherently insecure (unsecure?) they are.  Between users' laziness and apathy towards security and the ease which hackers can break your encryption hashes, a password just isn't enough to secure your most important resources.  Multi factor authentication, whether it is texting a one time PIN or smart cards or tokens, solves this security flaw. 

But at what price to the users?  You will have a rebellion of angry users if you require this extra level of security every time a user logs in.  But with careful implementation of a hybrid role based authentication and adaptive authentication methods, users will only have the extra steps when accessing important sensitive information.  And anyone can understand the need for that.

Let us show you how to accomplish this extra level of security without the onerous burden on your users.

Now you've done it, you have decided to look into an Identity & Access Management (IAM) solution.  There aren't a lot of these IAM solutions out there so it's pretty easy to narrow down the list of IAM vendors.  But, now you have to think, what am I looking for?  What am I trying to solve?

Gartner says that, "IAM ensures the right people get the right access to the right resources at the right time, enabling the right business outcomes."  I trust Gartner so you want to be sure that your IAM solution is doing those things.  Let's break it down:

• The right people: to know the right people you have to have access to all of the identity repositories in your network (HRIS, Active Directory, ERP, line of business apps, etc).  You need to know everything about these users and have a way to "join" the disparate user accounts.  You need to synchronize attributes and provision/deprovision.  You need to constantly inventory all of these systems for any change immediately.  An enterprise directory, or metadirectory, that joins these users and creates what we call a "person object" that links all user accounts gets you to the "right people."
• The right access to the right resources: you could call this identity and access governance or role based access control or even attribute based access control.  We call it all three.  This is the tricky part of all IAM, which is why we built our role engine into everything we do.  Role based provisioning, giving that "right person" the right user accounts.  Hybrid RBAC & ABAC, allowing you to get to an even finer level of granularity by not only looking at the user's role but also looking at attributes to define it further.  Role mapping to ensure that your IAM roles match your application roles (and you only have to manage them in one place).  Polyarchical role structures so that you can mix and match business and system roles for finer granularity.
• At the right time: On average, 20% of your users change jobs every year, that's called internal turnover.  You need to have all of your roles, provisioning jobs, synchronization jobs, and group memberships be dynamic.  This means that they are constantly inventorying every system for changes and kicking off a workflow to make changes to everything to ensure that the "right person" has "the right access to the right resource" right then and there.  It has to be dynamic, all of it has to be dynamic.  Think of it this way, automate automate automate!
• The right business outcomes: this is all about workflow.  Your IAM processes should map into your business, you shouldn't have to map your business process to your IAM solution.  A visual workflow designer that easily (this means without an army of consultants) creates business policy approvals, user approvals, and rights based approval makes all of these IAM changes map to what you need.  Think of it this way, when you are designing your business process, you draw it on a whiteboard.  Shouldn't your IAM process match that and not be lines of code.  Visual IAM workflow.

When you are looking for your IAM solution, this is what you want to look for.  EmpowerID has a pretty amazing solution to all of this and the track record to back it up.  Tell us what you want out of Identity and Access Management and we'll show you how to map it and get all of those bullet points right!

As our friends at XKCD have stated, "Through 20 years of effort, we have successfully trained everyone to use passwords that are hard for humans to remember, but easy for computers to guess."  Password strength has been reduced to p@$$wOrd123.

As a vendor in the password management space, I guess we should be thankful.  We are able to offer self service password reset, password synchronization, federated single sign-on and make a healthy living because of it.  And users are still going to be using p@$$wOrd123 but at least you can mitigate this security risk with a properly designed identity and access management (IAM) system.

Here are the things you can do from an IAM perspective:

1. Two factor authentication(2FA): for high security resources and applications, force 2FA.  Make a user have a cell phone or biometrics in addition to the password.
2. Identity proofing: make the user answer questions that only they would know in addition to the password.
3. Device registration: check to see if they are on a company-owned device before authenticating; if not, send it for approval.
4. One time passwords (OTP): when the user attempts to access an application, send an OTP to a secure email address (note: this doesn't work with authenticating into the network as that is where the email is :) ).

All of these are great solutions but the easiest and most effective fix you can do to ensure the best password strength:  password length.  Make your password policy a minimum of 20 characters and stop forcing upper case and special characters and numbers.  Heck, make it 25 characters or 30.

But, how is a user going to remember that if they can't remember p@$$wOrd123?  Easy, it's a sentence.  It doesn't violate the dictionary rules because it's a lot of words strung together and it's probably a quote the user remembers anyway.  Some to think about:

• franklymydearIdontgiveadamn
• Iknowitiswetandthesunisnotsunnybutwecanhavelotsofgoodfunthatisfunny
• itwasthebestoftimesitwastheworstoftimes
• allinallitisjustanotherbrickinthewall
• pleasenoteihaveneverusedanyofthese

Password length in and of itself doesn't guarantee security.  The best hacking programs can crack any password (especially one with words in it) very quickly.  But if you have a good lockout policy and, even better, two factor authentication, you can keep security very high and allow users to remember their passwords.

Password resets take up a huge amount of your help desk resources, some estimate one third of all calls are password related.  You cannot compromise security to reduce those calls so you have to do something.  I, of course, recommend self service password reset or federated single sign on with EmpowerID but at a minimum, or even in conjunction with, consider a higher level of password strength.

The best password strength is not always the most complicated....wait, that sentence would make a good password.