All-In-One Identity Management and Cloud Security

The traditional model for self service password reset drives me crazy.  The user gets asked questions to prove they are who they say they are.  And the system just resets their password.  Easy, right?  Secure, wrong.

Here is the issue, I can guess most of the answers to your questions by looking at your facebook timeline and the pictures on your cubicle wall.  Your first car, your daughter's name, your eye color, and so on.  That just isn't as secure as it should be.

What you need is two factor authentication with your self service password reset.  The first factor is the questions, in other words "what you know."  The second factor is something you have, whether it's a pager or mobile phone or a keyfob device.  With proper two factor authentication, someone is not only going to have to steal your user's memories but their phone also!

This still doesn't get you everywhere you need.  It is also important to have complexity requirements, either to match or exceed your Active Directory domain policy.  My own personal preference, make the complexity pertain to password length rather than crazy characters.  It's harder to hack a 72 character sentence than P@ssw0rd.  And it's easier to remember the sentence.

Having a proper password synchronization and SSO tool also improves your password security.  If users have a dozen passwords to remember they are going to make them easy to hack.  They are going to forget them a lot and use easy to hack questions.  Make life easier on your users and your security will increase...counter intuitive but true.

Get a second factor in your self-service password reset, it's easy and secure for your users.  Click below for a demonstration of how simple this can be.

Identity management runs on workflow, but not the traditional workflow of "who approves what".   Identity management workflow is really business process automation for identities. You, as IT, know what systems and resource access should happen if a new employee is hired, or fired, or moves departments.  The workflow is the process that makes that happen.

And you should not have to code anything.  Let me repeat, you should not have to code anything.

Let's walk through an example.  Bob is hired into sales as a Senior Account Manager.  The workflow sees a new employee in your HRIS, determines location, department, title and any other pertinent information.  Roles are assigned and the workflow automatically kicks off a process for provisioning into Active Directory, Exchange and Lync.  Everyone gets those.

Seeing that the user's department is sales, the workflow provisions a Salesforce.com account and since the user's location is Des Moines, the user is given an account for the badge system and access to the networked printer.

This is where it gets cool using rights based approval routing.  The user's title is Senior Account Manager...the senior means something around here.  Because of that title, the user is given extra privileges to send out mass emails using a 3rd party tool.  But because of the cost of said mass emails, you actually want to get the CFO's approval so a subworkflow is kicked off to have the CFO approve this right.

The identity management workflows can do even cooler things in the world of authentication.  Because the user is in sales and has access to account information, the SSO workflow forces two factor authentication the first time the user logs in from a new computer and forces password reset re-enrollment quarterly.

These, and many other, workflows can be created using a drag and drop workflow designer in EmpowerID.  Of course, you could try to create them yourselves using some other IAM softwares and an army of developers, but why?  With 370+ out of the box workflows and the ability to create and customize many more based on your requirements, make identity management workflow do your work with EmpowerID.

Schedule a demo and never have to approve another IdM workflow again.

User account provisioning isn't really rocket science.  You want users to be able to do their job from day 1.  What you don't want to do is just provision a user account in Active Directory and call it a day.

Remember this stat: a user is only 58% productive without the proper permissions according to the National Institute of Standards & Technology.  So, when provisioning a user, give them more than their AD account; provision that user to every system that they are supposed to be in.  Don't lose 42% of a user's productivity.

Consider what you know about a user from your HRIS: name, department, title, location, shoe size; all the relevant identity information for you to decide their most basic roles (you can determine more granular roles as you learn more about them).  From these basic roles, you can provision them into the correct systems.

To take that identity information and turn it into role based provisioning, you need workflow.  Workflow isn't just approval routing, it is the ability to set a business process within your provisioning and access control.  For example, the first box in this workflow is what location your user is in...depending on location, your user is provisioned into the proper card access system and put into the correct security group for printer access. 

Once that workflow is complete, every user returns to the next decision point based on department.  A user is provisioned and is given access to Salesforce.com if in sales or service, to Quickbooks if in finance, etc.  Of course, you can be more granular but people stop reading blogs if you get into too much detail!

Now the third workflow kicks in based on a piece of identity information not usually associated with roles: shoe size.  Each user/employee is given a pair of shoes for the company's annual Race for a Good Cause.  This is where the ability to have a hybrid of RBAC and ABAC comes in handy.  You want your supply chain software to provision a different color shoe based on departmental role, but also give the correct size based on an AD attribute.  Simple, a hybrid approach to RBAC and ABAC applies to provisioning as well.

Now your user has an AD account and, thanks to role based provisioning, has been placed in the correct systems and security groups, is operating at 100% productivity on day 1, and most importantly wearing the correct color shoes.

Click below to schedule a demonstration of how to manage role based user provisioning and extend it into an ongoing RBAC process.

Dynamic security groups in Active Directory are extremely important, not hard to do and inexplicably don't come out of the box from Microsoft.  Why are they extremely important?  To answer a question with a question, when was the last time a user came to you and asked to have some old permissions revoked?

They changed jobs and immediately demanded all the new permissions they now need and neglected to say, "hey, I was in operations, maybe you should take away my permissions to X, Y and Z."  Even if you are using roles, you are undoubtedly also using AD security groups.  So, manage them dynamically.

So, it's a given that you need to manage membership of AD groups dynamically, and if you follow that link above, you can see how easy it is, but what all do we use these AD groups for?

1. File and Folder access:  Windows is built on using AD groups for files and folders.  You want to manage these permissions efficiently to avoid token bloat but still give access to all the right data.  Most software systems give you an either/or situation....either manage membership dynamically or manage the permissions.  EmpowerID File Share Manager merges these ideas and allows you to dynamically manage membership and permissions.  Together.
2. Application access: this is a tough one because Windows does not support this in any way outside of its own integrated applications.  But these dynamic groups can and should be the method to access applications.  The key to this working is to have an authentication process which can recognize security group membership and roles, you know, something like the EmpowerID metadirectory.  SharePoint is an interesting example of this; SharePoint handles permissions based on AD groups but gives no way to manage the groups easily or well.  Make them dynamic and you have this solved.
3. Group Policy Objects (GPO): there is a subset of GPOs which apply well to groups.  Actions like applying desktop or IE settings by department.  You sure want to be sure to have the correct members in the departmental groups if you are doing this.

In all of these situations, if you are managing files/folders, applications or GPOs by AD security group, you run the risk of having out of date security groups if you are trying to manage them manually. 

A simple to use group management tool allows you to manage the membership dynamically; there are a few choices out there but the key to your choice is how extensible is it.  Do you want to just manage the membership?  Or add key components like what files/folders permissions does the group have and how do you incorporate provisioning and single sign-on to the applications based on group membership?

If you see the need for these dynamic security groups, let us show you a demonstration of the full value of managing the groups and what they can do!

The cloud is like the wild west right now.  Cloud applications are roaming the plains like gunslingers in a Spaghetti Western.  That's a crazy analogy but the point is that all the hard work IT has done over the last decade to corral identities within your network has been rendered useless in the cloud.

Everything you know about your user is rendered useless when they go out and create an account in the cloud.  A perfectly useful account for them to do their job but you in IT have no control over how they use it.  Or know what they're doing.  You have no idea what the user's cloud identity is: how they access it, what their account is, or if they should have access to it.

You need to understand their cloud identity.  The best way to get a user to buy in to IT knowing about their cloud life is to offer them something.  Cloud single sign-on is the best incentive to get users buy-in.  Think about it, if you want to know that weird little obscure account they are using, tell them you'll help them sign on more easily with their network account.

So, how do you integrate cloud identity into your network identity?  Workflow, beautiful role based workflow.  Let's take the biggest and most common example: salesforce.com.  In this example, you have 4 basic types of users who use salesforce: sales and service, user and manager.  Two departments, two roles in each.

If you have an IdM platform provisioning users and giving them roles (if you don't, please call us!), just assign a workflow that provisions the cloud applications like salesforce.  You know the user's role, so you can assign different permissions in salesforce to a sales manager v. a service user.

Once you've created the cloud account (in this case salesforce), you know the password, you have it linked to the user's network account.  You give the user single sign on to the cloud application.  Most cloud applications use some sort of standard authentication: SAML, WS-Trust, WS-Federation, and OAuth.  Now, between the provisioning, the SSO, and the role based access, you know what the user is doing in your audit and you have controlled the wild west.

Of course, in this scenario you have also controlled what they do on network.  And you might have dozens of cloud applications that you now control.  Identity in the cloud is NOT different than identity on the network, you just need a way to manage both together.

Role based security means an awful lot more than just role based access control (RBAC).  It means using RBAC to its fullest potential to secure all resources in and out of your network.

This means having an identity management platform that is built on the idea of roles.  Provisioning to different systems based on roles.  Granting access to resources based on roles.  Workflow levels based on roles.  Single sign-on based on roles.  Roles have to be core to the identity and access management platform that you choose.

IdM platforms built from acquisitions and hodge-podged together have a hard time having a core platform belief system like this.  The components need to be able to talk to each other seamlessly in the same language (not just programming language either).  For example, if you are provisioning only certain roles into salesforce.com, then your single sign-on has to understand that role and work with it, only allowing those users to even go through the SSO process.  Otherwise, you get moving parts; Frankenproducts love moving parts, business productivity doesn't.

A great example of this is rights-based approval routing (lovingly known as RBAR).  RBAR unifies workflow and RBAC security to enforce real-time evaluation and routing of who can approve what based on the actual rights delegated to the current person at that time for the affected resource.  Approvals route to approvers with the necessary privileges to perform the intended operation. Those rights are determined by your role.

Using RBAC and Attribute Based Access Control together is even better.  Picture you are in the Sales in Toledo role so you are provisioned into Salesforce as a user.  But you are a manager as shown in your title attribute in Active Directory.  Using the RBAC/ABAC hybrid allows your IdM platform to approve requests around Salesforce access and/or have extended privleges within salesforce.

Take a look at our whitepaper on Best Practices in Enterprise Authorization - the RBAC/ABAC Hybrid Approach.  You will get a great idea of how this all should work with a proper platform built with a foundation of RBAC.

You want your users to be able to log in to the network, their on premise applications, their cloud applications and all of your partner applications.  You want your partners to be able to log in to the applications they need.  And you want this to be easy; both for the users involved AND for the IT security team that needs to make it happen.

A flexible stardards based federation solution is the key to solving these critical business challenges by enabling users to login once and then access applications without being prompted to login again.

Single Sign-on (SSO) is the most important service offered by identity federation because it allows employees, customers and partners to access multiple Cloud or internal corporate applications using a single username and password.  If done right, federated SSO allows users who are authenticated against one directory to access additional applications and services without re-authenticating hwne a trust relationship has been established.

The key to "doing it right" is to keep from re-inventing the wheel, there are standards to follow and trailblazers who have done it in the past.  We inventoried and queried our customer base to boil down the top 5 scenarios for Federated Single Sign-on (SSO); take advantage of our hard work to make things easier for you!

Top 5 Federated Single Sign-on (SSO) Scenarios

• Scenario 1: Corporate login to Cloud Application
• Scenario 2: Cloud login to Internal Application
• Scenario 3: Corporate login to Internal Application
• Scenario 4: Corporate login to Partner Application
• Scenario 5: Identity as a Service (IdaaS) Hub

In each of these scenarios, what differs is how the user authenticates and what they can access.  Using a variety of standards (SAML, OpenID, WS-Trust, WS-Federation, OAuth) and Identity providers (Active Directory, LDAP, Facebook, OpenID, Salesforce.com along with many others), these scenarios will allow you to ensure that the correct user can access the correct applications easily without extensive help desk calls.

A blog is no place for the technical how-to's of each scenario so we have published a whitepaper with a description of each, benefits of each approach and how to accomplish this feat.  Download the whitepaper and start designing your Federated Single Sign-on.