All-In-One Identity Management and Cloud Security

Your finance department is watching the cloud.  Not because they are tech literate and following IT trends, but because they can cut your budget quickly with cloud applications.  And it's up to you to help them before they help themselves.

In the on premise world, if a user leaves the company and you keep an application account for a few extra weeks, it only hurts your security.  In the cloud world, you just paid an extra month of service for a user account you didn't need to.  Take a look at your internal and external turnover, pull out a calculator and see if you can make a dent in your budget by managing your cloudy accounts better.

The way I see it, you have two simple options to help you reduce your monthly cloud expenditures:

• timely provisioning & deprovisioning of all user accounts
• role based provisioning to the cloud applications

The first is obvious, if a user leaves the company, you need to deprovision ALL of their accounts, on premise and cloud.  A metadirectory that has inventoried all of their accounts from connected systems (AD, HR, ERP, Salesforce, Gotomeeting, etc) can delete or deactivate those accounts quickly and easily.  This is your external turnover.

But what about internal turnover?  That user who moves from marketing to sales and needs new access to some systems (SharePoint sales site and the line of business quote application for example) and different access to other systems (like Salesforce)?  And they certainly don't need access to applications like their cloud based marketing automation software (Hubsport or Eloqua).

They are going to have a different role in your metadirectory (now sales in Iowa instead of marketing in Ohio) and that can trigger the workflows that will provision new user accounts (in that quote application), change access in some (a different native application role in Salesforce), and deprovision access in their marketing automation application (like HubSpot or Eloqua).

Did you see what just happened by managing application access and provisioning by roles?  We just deleted a cloud based application account (the marketing automation account) and saved the company money.  Every single month.  If you are handling this manually or allowing the line of business (marketing department) to manage it, chances are the company is paying for a lot of cobwebbed accounts in your cloud applications.

Keep finance off your back; take a look at empowerID to manage your role based provisioning for the cloud.

The bane of every SharePoint project is permissions and rights.  Access is controlled via SharePoint groups, these quirky little groups that exist in the SharePoint vacuum and only in the SharePoint vacuum.  SharePoint 2010 introduced the ability to control access via Active Directory groups but gives no way to manage the membership of these groups.  So you end up with site admins managing permissions manually or just letting it die on the vine.

What if you could do true role based access control (RBAC) within SharePoint?  Have dynamic roles for your users that change as the user changes (new department, title, location, etc)?  And then manage site permissions with these roles?  Thanks to SharePoint 2010's claims provider functionality you can.

If you set EmpowerID as the claims provider for SharePoint, it exposes EmpowerID roles in the "People Picker", allowing the site administrator to pick a role (for example, HR managers in the investment banking division) to have access to that site.  These are the same roles that will be used for resource permissions or application access.  And it is possible to see who is a member (if you have permission to view membership of that role) from within SharePoint, making it possible to ensure that the right people have access to the right SharePoint resources.

The thing about roles is that they don't have some of the side effects that Active Directory groups do such as token bloat.  You can be a member of as many EmpowerID roles as you want without impacting your ability to log into the network.  On top of that, EmpowerID offers a polyarchical role structure so you can pick that HR manager role in investment banking from two trees, limiting the number of roles that you need to create.

Having a true SharePoint RBAC system also allows you to manage separation of duties since you can set an SOD rule that says a user cannot simultaneously be in two conflcting roles.  You don't have to worry about accidentally giving an investment banker access to the retail banking SharePoint site.

SharePoint RBAC is just a lot more flexible than managing permissions with groups (either AD or SP).  You get all the benefits of maintaining permissions dynamically without the overhead of managing a completely different set of access infrastructure.  This same claims provider functionality gives you SharePoint single sign on capabilities for your external partners for example without having to have AD accounts for them.

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.

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.

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.

SharePoint's People Picker is one of the strangest user interfaces in the world.  A SharePoint site admin generally gives permissions to either SharePoint groups or Active Directory groups.  But if he/she uses AD groups, he/she doesn't know who is a member.

You can solve this conondrum with dynamic Active Directory groups but that still falls short.  Active Directory groups have all sorts of issues with forests and domains and what if the user doesn't exist in AD?  Many SharePoint instances are a combination of access for employees, contractors, partners and customers.  It would be nice to manage the SharePoint permissions for each of those in one central place.

Luckily, SharePoint 2010 supports an external directory as a claims provider.  EmpowerID's metadirectory functions as the claims provider and offers federated single sign on to SharePoint.  And this opens up the world of roles (static or dynamic roles) to SharePoint.  SharePoint permissions management becomes more robust as you can have roles in EmpowerID that reference any identity store, not just AD.

EmpowerID’s powerful hybrid RBAC and ABAC model can be used directly inside SharePoint’s People Picker user interface to grant access to sites, lists, documents, etc. The People Picker allows end-users to search and select any EmpowerID security object such as People, Groups, Roles and dynamic collections just as they would normally search for users or groups.

The EmpowerID RBAC system allows content owners and security administrators to use flexible and dynamically maintained role-based assignments when managing SharePoint permissions. The dynamic nature of these roles can dramatically reduce the administrative burden of manually setting security assignments and automates access granting and revocation based on changes in user’s job status, function or location.

Role based access control (especially when mixed and matched with attribute based access control) gives SharePoint a ton of flexibility in how you assign permissions within SharePoint.  That customer can get the exact access they need (and even SSO) without lifting a finger.  Your SharePoint team can publish internally and know that role based permissions are keeping it safe.

This is all built-in functionality to EmpowerID, let us know if you'd like to see it in action!

Talking to a client the other day about enterprise to cloud access, it became apparent that before considering cloud SSO, cloud provisioning needed to be taken care of.  More than that, role based cloud provisioning.

And this is where it gets tricky in the IAM marketplace.  There are a few companies offering cloud single sign on and doing it well.  They just don't have the platform in place to integrate with the on premise world and do role based provisioning to the cloud as part of that solution. 

And, think about your business goal here for a second.  You want to make sure that the right users have the right access to the right applications.  So, first you need to do role based provisioning; anyone in sales and support needs access to salesforce.  Only those users should be provisioned; after moving to another department they should be deprovisioned.  Data security is one thing to consider but so is license consumption...you pay monthly for these licenses.

Once you've provisioned the correct users to the cloud application (in this case salesforce), you need some role mapping.  That sales rep should have different access than the sales manager than the support rep.  Map your corporate roles to the cloud app role and not only do you get user accounts for the right folks but they get the right access.  As they move jobs, the dynamic role in your enterprise directory maps to the cloud role and presto boomo, accurate access to cloud applications!

And, now for the thing that people worry about.  Cloud single sign on...federating with the cloud application.  This is arguably the least important step but the one that gets the most attention.  Who cares if you only need one password if you have the wrong users getting access?  Luckily, it's possible to do all three and leverage the same directory if you can do SAML federation from the directory that is handling the cloud provisioning and access.

There must be others doing all three aspects of this cloud provisioning, but if any of this rings true to you, schedule a demonstration of EmpowerID and see how to get the right users the right access to the right cloud resources, and SSO them while you're at it!

If you are going to adhere to the principle of least privilege, you also need to consider temporary privileged access.  The idea is that a user and/or administrator should not always have privileged access but will probably need it for a short amount of time.

To do this, you need a few things:

1. a mechanism to request access
2. a workflow to approve the request either by business rules or user approval
3. a mechanism to grant and revoke access in a specified amount of time
4. a mechanism to extend the privileged access
5. a mechanism to audit and report on this access and
6. a "break glass" method of emergency access

In short, you need a robust role based access control (RBAC) system.  If you have all of these pieces you can avoid the inevitable outcome of the off-duty admin saying, "OK, just this once, use my credentials"!  Yes that happens.

Let's think through a use case.  Your internal developers have created a web app that is crashing, they don't have access to production but need to run some tests and troubleshoot what has happened.  They could work with an IT admin and get it done using their credentials but that doesn't always work.

So, they go to their access request portal and request access to the production system.  Based on their role or admin approval, they are either immediately granted membership in a role for 24 horus or a one time password (OTP) that expires after 24 hours.  Either way, steps one through three are achieved.  The developer has access, it's been approved but it's going away in a specified period of time.  They get to work troubleshooting.

One day later, they are still working at it and get a notification that their access is about to expire.  They apply for an extension and it invokes the workflow again.  Maybe this time, the request needs a VP of IT approval regardless of the role the developer is in.  The workflow should be able to handle any business rule you put around the temporary privileged access.  Still, step four done and accounted for.

And "accounted for" is a great segue to the need to report and audit such access.  If this is a sensitive system, or even if you are just a highly regulated industry, somebody needs to say who had access to what, when and who approved it.  Any changes within that system needs to be accounted for and the auditor will need to know how "developer X" got access.  That's step five.

Now, the tricky one, the break glass method.  Go back to the beginning of this scenario, it's Saturday at 2AM and your revenue producing portal crashes.  Nobody can fix it but the developer and your business rules require a VP to approve his access request.  However, that VP is in Fiji enjoying a hard-earned vacation. 

Having a way to circumvent the normal approval process in an emergency is a must.  The workflow takes a different route if this is deemed an emergency request.  Maybe a director can approve it but it will send red flags throughout the auditing community and require a retroactive VP approval to keep them from sending in the infantry.  This gives the emergency access (you still have all of the auditing of who did what and when from step 5), keeps a strong sense of security, gets the project done and keeps you in regulatory compliance.

This need for temporary privileged access (TPA I guess we could call it) happens constantly.  The workarounds are dangerous from a security standpoint if you don't have a mechanism in place.  The effect on your business is probably worse if you just ignore the need.  And you still stand on the high and mighty pedestal of Least Privilege!

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!