All-In-One Identity Management and Cloud Security

A customer was showing us his current state of role based access control for their business intelligence application.  What had happened was that for each segment of BI reporting, he had to create a role.  The real issue was that each of those roles was needed for each region.  So suddenly he had 10 management roles TIMES 4 regions for a grand total of 40 roles that he needed.  Just for his BI app.

He needed an easier way to manage this.  Their solution had been to allow an EMEA user to request North American access and then the approver had to deny it.  It was confusing for both the access requester and the approver.

What helps this is our combination RBAC and ABAC (attribute based access control) hybrid model.  10 business roles are defined and then access requests are security trimmed based on the requester's region (an attribute in the directory).  Attribute based access control allows you to take an actual role and get fine grained for the access request system without the requester even knowing it is happening.

We could even fine tune it further by using rights based approval routing (RBAR).  Let's say they want to define it that anyone in a certain department gets auto-approved, RBAR does that while still requring approval for someone outside of that department even though they are both in the same role!

Remember that the whole goal of Identity Management is to get the right user the right access to the right resources.  What is left unsaid there is "with as little IT interaction as necessary".  You can add some components like ABAC and RBAR on top of RBAC to map these workflows to your business process.

In the end, the customer won't need to create an exorbitant amount of roles, they reduce the back and forth approval process, and make it easier for the end users.  Then for the auditing and intelligence portion of IDM, you'll have a full report and view into whether a person approved the access or a business policy did.  You will be conforming to least privilige principles by security trimming what a user can even request.

Take a look at this whitepaper if you want more information.  If you are ready to start controlling your access with EmpowerID, we'll show you a demo and prepare a trial for you!

One of the  main issues with access requests by your users is they don't know what to ask for!  Think about it, your user knows that they want to see the prior year's sales results sorted by average receivables age.  They go to your access resource catalog and sure enough there isn't a resource named that.

You and I both know what they want is something called sales manager role in QuickBooks but that translation is not apparent to your user.  How do you solve this?  You can't name your role based on what they want to do because other users in that role have other needs.  You can't necessarily have them ask to mimic Bob in the Scranton office's rights because you might have granted him a higher level of permission (never violate least privilege if you can help it).

Until we can intuitively read the user's mind and translate on the fly, we need a way for the user to understand what they're looking to do and assign permissions for that particular task.

We thnk the best way to do that is with access bundles.  This way you don't have to create a bevy of highly specific roles but you can bundle a bunch of access into an access bundle that has multiple related access rights.

And that's where access certification and re-certification comes in.  If you grant this access bundle to a role, user or group, then they all have it until time comes to an end.  This shouldn't be.  Any access request that is granted needs to be attested to often.  The best recommendation is to grant access for 3-5 days initially, if the user still needs it after that they have to request to renew this access.

This request should kick off a workflow to the resource or role owner to certify that the user, role or group still needs access.  At this point, they can grant access permanently, for a set period of time or deny permission.  This certification process can vary by resource or the role of the user requesting. 

View access as a privilege not a right.  But if you are going to keep this principle of least privilege, then make it easy for access requests and certification.  Next time we'll go over the fun part of designing your catalog of access bundles!

If you want to take a look at how this works, we can give you a demo and trial of EmpowerID, just click the beautiful button below!

There are some things that only your users know.  So why not make them the authoritative source for that identity information?  Some examples would be mobile phone number, home phone number, emergency contact information, and oddball information like shoe size.

Providing Active Directory self service gives you a good place to store this data.  Most of these items have attributes in AD and you can easily synchronize that information from AD to your HRIS or emergency notification system.  You can even then start making dynamic Active  Directory groups based on the information.

But you don't want to open ADUC to just anyone so you need a role based Active Directory user interface for self service.  The reason for role based is you need to have security built in to the self service web page so that I don't go and change my colleague's title.  You'll need to have rights based security allowing a manager to change some fields for their employees and the employees to have access to change other fields.

You then want rights based approval routing to make sure that somebody is there to approve any changes that need approval, whether via email or an approvals dashboard.

We have a whole whitepaper on how to replace ADUC, take a look.

But then there's another issue.  What if Active Directory isn't the place to store the information?  For example, you have union employees who need to update their union membership with HR every once in a while.  You don't want that information flowing through AD to get to your HRIS.

We solve that with a metadirectory.  The metadirectory has pretty flexible attribute flow rules so you can create a self service page using our forms designer, have it update the metadirectory (again, using rights based approval routing) which flows directly to HR without AD being in the middle.  To use technical jargon, presto bammo, you have self service updates without IT having to be involved.

This is probably EmpowerID's most basic and simplest use case, with almost the entirety of this functionality able to be installed, configured and deployed in two hours.  Give us a shout for a demonstration and we'll have you up and running in no time, delivering Active Directory self service for user and group management.

You know that guy in accounting you just don't like and wish you didn't have to talk to?  Well, there's a chance that you don't have to!  Separation of Duties (SOD) to the rescue.

It doesn't really work like that but there are some mutually exclusive roles.  One where if you have these sets of permissions, you cannot have another set of permissions.  Some of these are security related (for example, you have permission to create a user, you should not have permission to add them to the financials group, this keeps one person from being able to create a fake user to access critical financial reports).  Some are regulatory (for example, in a bank the analysts should not be able to have access to customer records, the bankers should not have access to analyst reports).

Once you are controlling permissions and access with roles (using Role based access control aka RBAC), it is simple to make roles mutually exclusive.  If you are a member of one role, you cannot be a member of another.  If you are a member of one role, you need CEO approval to be a member of another.  This creates a separation of duties.

I always picture it in action like a Hollywood movie...you need two keys to detonate the bomb and there is a tense standoff as the one guy knows they shouldn't do it.  Separation of duties is just like that.  Just. Like. That.

Once you've configured your roles to show what your users can do, you need to take that next deeper dive into what that same user shouldn't be able to do.  A good mapping of roles and SOD rules will make your organization more secure and your auditors much happier. 

If you are one of those "a picture is worth a thousand words" types, give us 15 minutes to show you how SOD works in RBAC by scheduling a demonstration.

Back in the old days, user account provisioning meant "get that guy an Active Directory account" {note: old days not that long ago}.  And the world was easy, provision an Exchange mailbox and your user could get going, productive as the proverbial bee.

Today, you have bigger fish to fry with cloud applications, multiple AD user accounts, line of business applications, and myriad other accounts that need provisioning.  This all has to be sorted out, provisioned based on roles (marketing probably doesn't need access to financial systems, engineering can probably do without SalesForce access for example) and kept constantly updated.

Having a "people directory" solves this.  Each person has an account that is linked to all of their user accounts whether it be Active Directory (Exchange, Lync, etc), CRM, ERP, weird cloud applications.  Workflow rules can provision the user from an authoritative source (usually the HR system) and give them all the accounts they need based on their role (I love role based provisioning!).  A constant inventorying process will detect any changes and change access based on that.

Your user leaves the company?  Boom!  De-provision all of the accounts at once.

Take a look:

User provisioning and deprovisioning should be that simple and that automated.  Joining user accounts, monitoring directories and databases for changes, keeping accounts active that should be active, inactive that should be inactive.  All done because you have a "people directory."

The first time I saw that graphic, I already realized the benefits of this type of automated user account provisioning.  I've seen enough complex corporate environments to know how important this is.  But it was the box at the upper right that knocked my socks off.

Users can authenticate against this directory.  That means that using SAML or WS-Trust or other standards, we can federate with any application that supports it.  Users get not only the benefits of role based provisioning and RBAC, but single sign-on as well.  And, the people directory obviously knows what apps they should have access to, heck, it provisioned those apps.

Let's summarize: lots of applications and systems, easy provisioning and deprovisioning, role based access control and federated single sign-on.  Would it shock you if I said EmpowerID makes this easy and installs and configures in a fraction of the time you would expect?  Let us show you, schedule a demo.

SharePoint is becoming more and more prominent both internally and externally.  Since access is often a hybrid of internal and external users, SharePoint identity management is especially important to do right.

You have to make it easy for these users to access the correct SharePoint sites based on their role(s).  An internal user needs certain access and an external user needs different access; it's like two sides to the same coin.  For example, both need to access billing records but have different permissions on what they see.

Where things differ is the user experience.  You manage internal users based on having Active Directory accounts and then grant access based on SharePoint, AD, or other groups and roles.  External users have a whole different set of identity issues.  You don't necessarily want them in Active Directory so you don't manage them with AD groups or even SharePoint groups...so how do you manage them?

Having an external directory that can manage SharePoint permissions and assign roles is essential.  Our own product, EmpowerID, does that very well.  Once you have the directory for this, there are three main user experience components you need to address:

1. Registration
2. Login and SSO
3. Password Reset

Since they aren't internal users you may not have an authoritative source for these users.  If you do, provision them from there.  If you don't, you need a registration page that collects the relevant information and sends their details to the appropriate system or person for authorization.  For example, anyone can have general access, but if they indicate they are a customer, have the registration page confirm with CRM or their account rep.  Keeping these external users in a separate directory allows you to manage their access with the proper granular controls.

A user needs to be able to login easily.  Accepting federated logins from Facebook or Google enhances the ease of your portal for customers.  Having a system to accept federated SAML tokens is needed for this.  SharePoint 2010 allows directories like EmpowerID, for example, to act as a SharePoint claims provider.  This way, users don't have to remember another username and password.

But if you don't federate, you will need a good way to allow a user to reset their password without calling you.  Since you are often displaying important confidential information to your external users, having a method for two factor authentication or identity proofing will keep this data secure.

Remember, the fewer barriers to having your external users interact with you, the more likely they will continue to spend money with you.  Understand their identity, provide them the same or better service than you do your internal users and you will keep a customer for life.

Schedule a demo to see how some of our customers have solved this identity management issue with SharePoint and see how to improve it for your customers.

I am a big fan of role based access control (RBAC).  My entire product line is built on the concept.  Roles control what systems a user gets provisioned in, what level of access they have in those systems, what files and folders they can use, and basically how they do their job.  Having multi-hierarchical roles means that you don't even have to define every single role, they define themselves.

But even with the greatest role structure ever created, there is going to be that one folder or that one system or that one cloud application that is just a bit different.  You don't want to have to create a new role for this one single use case, you might just want to modify it a bit.

Enter Attribute based access control (ABAC)!  Attribute based access control is the concept of having your permissions defined by an attribute in Active Directory or other system to determine if the user has access. Combining its power with RBAC gives you the best of both worlds.

Say you have an HR Manager in the Southwest region and your RBAC rules gives him/her and all of his/her peers access to applicant resumes either in a folder or your HR system.  But, your company is in the process of hiring a new CFO.  Somebody has to review those resumes but it is highly sensitive and only one manager is tasked with it; the rest should not be able to see them.  You don't want to create a new role just for this one task but you know that certain managers are identified in AD as "top secret clearance".

When creating this new access, just use the HR Manager Southwest role, then add the attribute of "top secret clearance", and anyone in that role with that clearance is given permission to manage these resumes.  As users' roles and clearances change, that access will always be dynamically assigned to the correct users.

I have often heard, "how is this different from dynamic groups?"  Dynamic AD groups mostly are used for file systems; we offer these as well, but to have dynamic role or hybrid role based and attribute based access allows you to extend these permissions past the file system and out to provisioning, application access, even to the cloud applications.

If I didn't describe it well enough or if that cool picture didn't really cover it, let us show you how it works with a personalized demo.  With an RBAC / ABAC hybrid structure, your users will have the exact access they need when they need it.  Also, download the whitepaper!

Managing your internal identities is the bread and butter of identity management.  You know who your users are (at least you should) and you have a good idea of what they need to do their jobs.  If you don't, call us and we'll get EmpowerID running toute suite.

But there is a whole new realm of identity management you need to think about: partners and customers.  Your external identities.  You don't hire them so you probably don't have a tried and true process of provisioning.  You certainly don't want to give them Active Directory accounts but they need access to a lot of services and systems that you provide.

We are seeing more and more of this in the marketplace, how to expose services to your external identities and how to track them.  It sounds just like identity management but not all of the traditional solutions work here.

This is where the platform approach really works.  You can provision new users, heck even offer self-provisioning, and assign roles immediately.  These roles have access to certain parts of the application or portal.  The IAM platform can confirm that this is indeed a customer in the CRM system, and provide advanced access or more privileged roles based on any number of criteria that you know about them.

By storing this external user identity in the metadirectory, you can authenticate directly against that directory, utilizing SharePoint 2010's claim provider functionality.  Now, in one place you have provisioning, role assignment, and authentication.  You can easily keep track of your external users, have an audit trail of their authentication and role changes, and manage external customers and partners like they're employees.  But easier.

Gone are the days of trying to create a separate domain for external users and not being able to restrict access to customer facing applications.  Utilizing the EmpowerID platform, you can treat customers, partners and other external users with the same role based security that you do your internal users.

Take a look at what we did for a very large insurance and healthcare portal to help manage access for external users and schedule a demo now!

We get involved in some very cool intricate discussions on identity management; delving into federation, RBAC, provisioning workflows, all the really fun stuff.  But sometimes you have to step back and realize that there is some blocking and tackling needed.  You need Active Directory self service.

End users are an incredible source for identity information and permissions management.  What you can't automate, delegate.  And this is very true.

The problem is that Active Directory houses some very sensitive information and many extremely important business processes are keyed off of it.  As such, you can't let an end user change their title or direct reports or gain access to the shared folder that houses the 10Q documents.  So, when delegating, keep RBAR in mind.

What's RBAR you say?  Rights based approval routing.  The idea that you take your roles and assign what can and cannot be changed in AD based on who is asking.  If it's the title attribute and the requester is the VP of HR, you let the change happen.  If it's the mobile phone number and it's the user requesting it, make the change.  If it's the telephone number and the user's manager asking, route that approval over to IT for an official OK.

It's really that easy.  It takes IT out of the process unless it's something that they need to know and/or approve.  It gives control to the business owner who should know what needs to happen.  And it maintains the integrity of Active Directory.

This RBAR concept also applies to Active Directory group management.  Different groups have different levels of security.  Anybody should be able to join the "book of the month club" group; but an approval should be needed to join the "Top Secret book binding project" group.  CEO approval should be needed to join the "10Q analyst call" group and HR approval should be needed to leave the "Employees on probation" group.  RBAR it.

What happens when you flip the tables and offer file share access via self service?  Nothing different, apply the RBAR concept to requesting access to a resource.  Don't just rely on the outdated AGDLP method to manage access, utilize roles and RBAR.

I could go on and on but our whitepaper already did that, discussing how to delegate permissions into AD without giving permission to AD.  Take a look.

When you start work in the morning, you authenticate against Active Directory; when you start thinking about identity and access management, you start thinking about Active Directory.  Active Directory is at the heart of it all but is often oddly neglected.

Identity and access management is a lot of things: user provisioning, user deprovisioning, single sign-on, role based access to systems and resources and my favorite the whitepages.  Seriously, the whitepages.  The whole point is to enable employees to do their jobs and one of the lacking things in many organizations is the ability to find co-workers.

Active Directory provides the mechanism for this but often times is neglected.  Take the "Mike Smith example".  In an organization of over 10 people it is statistically probable that there is at least one Mike Smith; in any organization over 100 people it is a statistical certainty that there are at least three Mike Smiths.  This is advanced math, please trust me.

There are a few ways to tell these Mike Smith Dopplegangers apart...department, title, location, middle initial, picture, et cetera.  And the global address list exposes these.  But what if these attributes are not in Active Directory, as they very often are not.  You have to synchronize Active Directory with your HRIS or other authoritative source.  And do it often because department, title and location change.

Easier said than done, you say?  Well, no, it is as easy to do as say.  Synchronizing Active Directory is one of the most elemental and easy accomplishments in identity management.  Most, if not all, IAM platforms eat this stuff for breakfast.  EmpowerID is configured to do it in the first day of implementation, if not the first morning.

As mentioned above, IAM encompasses a lot of great functionality, but let's start with Active Directory.  Make it accurate and the rest of your day just got easier.  Give us 30 minutes to demonstrate this building block of IdM and we think you'll go out and solve your own "Mike Smith" problem.