All-In-One Identity Management and Cloud Security

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.

What makes EmpowerID different?  In the crowded Identity and Access Management (IAM, also referred to as IDM) market, our slogan, “A new breed of identity management“ and a little of our history are helpful in understanding the answer to this question.

By 2005, we had spent three years developing and deploying an easy to use and quick to deploy Self-Service Password Management and User Provisioning product.  We realized that clients were consistently asking for many of the same features that couldn’t be found in one offering:

1. The lower cost and ease of use of an application, but also the power and flexibility of a platform
2. The ability to make Identity Management processes conform to their business practices, instead of making changes to accommodate the limitations of an IAM application
3. A modular approach that allows them to buy just what they need now, with the ability to add support for additional directories, platforms, applications and federated single sign-on (SSO) later
4. Freedom from vendor bias, meaning that they don’t want to sacrifice strong support of Microsoft platforms to get strong support for an Oracle, SAP or IBM platform, or any number of other standard and custom applications
5. A high degree of integration among the moving parts of an Identity and Access Management (IAM) platform and a “single pane of glass” to see security across all connected applications, platforms and directories
6. Powerful Role-Based Access Control (RBAC) that allows them to quickly configure access, views and control by a wide range of hierarchies and locations, but which still can have rights added or subtracted manually
7. A standalone Metadirectory that allows them to store information and extended attributes without stuffing them into an internal system like Active Directory
8. Highly flexible, modern user interfaces with “rights-trimmed” user views and support for corporate theming

The first thing that struck us when we reviewed this list of client requests was that we had to develop a fresh, innovative vision if we were to achieve all of these objectives in one solution.  We concluded that we had to think in terms of a platform, by which we mean a common set of code, logic, services, tools, and interfaces that could span every module that we would want to develop in the foreseeable future.  This platform would also have to offer redundancy, high availability and scalability to meet both the demands of the largest enterprises and the rapidly growing number of organizations that need to securely manage Identity information for their partners and customers.

Cobbling together different applications through licensing agreements or acquisitions would not accomplish a key goal for us that has eluded all other major vendors in the IAM market: producing a full-featured platform that could meet all of a client’s major goals while costing significantly less to develop and to expand, as well as costing our customers less to acquire and to maintain.  Key to this would be to build the entire platform on a single codebase that would allow for the accelerated development of new modules and features.

We realized we had only one option to include all of the items on our clients’ wish list: to start from scratch.  By taking a “greenfield” approach we sought to avoid the architectural and design constraints that limit our competitors and to allow us to offer a breakthrough price point for enterprises that had been excluded from acquiring traditional IAM platforms by their high initial cost and their labor intensive implementation and support requirements. 

Our first task was to decide which key elements would be essential to include in this new platform approach to Identity and Access Management, and these are the core components of EmpowerID that when combined make it truly different:

• Workflow – not just a series of simple approvals that other vendors offer, but rather a comprehensive Business Process Automation (BPA) platform that provides the mechanism for executing every action taken by the IAM platform against other connected directories, applications and platforms.  We ship with over 375 workflows in our complete suite that can be installed and can start performing work in a day.  Our visual workflow designer can modify any workflow and create new ones and allows business managers to collaborate with developers by allowing them to see how IAM information flows and is controlled throughout their enterprise.  It collapses the time for producing client-specific customizations and it creates productivity gains through automation.

• Metadirectory – a robust directory that stands apart from all other connected directories so that it can function as a full authoritative source of the “truth” about any identity and its attributes as provided by direct input to it, or by inventorying or directly querying in real-time any connected source.  This Metadirectory can be used to create and manage the lifecycle of an identity independently of any other directory.  It can exist outside of a corporate firewall to safely manage the increasingly complex world of Federated and Cloud Identity.  The Metadirectory also functions as a directory, enabling organizations to allow external partners and customers to authenticate without creating user accounts in the corporate Active Directory.

• Role-Based Access Control (RBAC) – some applications claim to offer this, but a major platform must extend a robust vision of managing roles.  EmpowerID’s RBAC can determine rights from multiple hierarchies and locations.  It works in conjunction with Attribute Based Access Control (ABAC) and another unique contribution we have made to this technology, Rights Based Approval Routing (RBAR), to create remarkably powerful and efficient security with sophisticated approvals, Separation of Duties (SoD) and Attestation capabilities.
  

• Flexible and modern User Interfaces (UI) – this would seem to be an obvious component, yet it is frequently overlooked by many vendors, despite being the face of the application that all users encounter.  We were determined to lead the industry with highly configurable UI that not only allows the security to control each user’s view, but that also enables client branding to create a rich user experience.  This is an important component in driving user acceptance and adoption of self-service components.

So how have we done?  In the four years since the first release of the EmpowerID platform, we have achieved a global presence in some of the world’s largest organizations and in market segments that include: finance, banks, regulatory agencies, governments, energy producers, healthcare, retail, manufacturers, advertising agencies, manufacturers, primary and secondary education, and software developers, among others.  We have single installations with hundreds of thousands of users managing millions of objects and many projects that connect and provide Identity Management for Cloud applications.

The distinguishing characteristics of our wins include:

• We are highly competitive on the pricing of the EmpowerID suite while  offering lower implementation costs and shortened project timeframes due to our requiring less of the custom development and heavy scripting that characterizes our competitors
• We have replaced many IAM applications or we coexist and interoperate in environments with existing IAM investments because of our ability to incorporate existing code with our open workflow platform and our flexible connector and communications models
• Clients make extensive use of our workflow, using it to automate and to design and automate many non-IAM functions because of the extraordinary capabilities of the platform that allow it to drive efficiencies with secure Business Process Automation.  Some clients have gone as far as to build complete applications on their own using our workflow designer.
• We retain responsibility for a successful completed project – we don’t push our clients to buy EmpowerID independent of delivering a successfully completed project like much of our competition that relies on partners of varying quality to deliver a finished result

We continue to aggressively develop EmpowerID, with the release in March of the 2012 version of EmpowerID in conjunction with two new modules: SSO Manager, which integrates Federated Single Sign-On (SSO) into the platform and File Share Manager, which provides shared folder permissions inventory and management.

EmpowerID allows enterprises to securely manage their identities while generating cost-savings from automating and securely delegating tasks.  Our goal is to continue to make Identity and Access Management easier to implement and easier to maintain, permitting an increasingly broader range of enterprises to own the critical IAM technology they need to realize their automation, compliance and Cloud goals.

Discover the new breed in IAM software by exploring EmpowerID.

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!