Moving your identity management to the Cloud brings a lot of freedom, as well as the controls to keep it secure, but only if you have a strategy in place to make it so.
It’s a widely accepted fact that cloud as an IT service is here to stay.
Salesforce is now 20 years old and other cloud-based services go back even further; mail.com was started in 1995, Hotmail in 1996 and MSN Messenger arrived on the scene in 1999.
The revenue garnered by cloud services was £145 billion in 2018 and grew to £171 billion in 2019. So, how we control those cloud services is very important.
Ever since the perimeter of the office network disappeared, it has been more and more difficult to manage, control and secure access to data and services.
With the advent of the iPhone in 2007 and then the iPad in 2010 (and other rival smartphones and tablets), users started to request access to their services from these new, easy to use devices.
When the CEO started to ask, it became more difficult to say no!
In effect, this meant that the control of the hardware and network disappeared. Of course, this is not really news anymore – it’s something that we’re all familiar with.
This really meant that the only thing that we could “own” was the ID of the user that was used to access the services. Creating this ID and keeping it up to date was a function of the service desk (actually, in those days, it was more likely to be a network administrator). A request would be created, often on paper, and the relevant account created or updated.
Now we have cloud services, this isn’t a problem anymore because, after all, these services are all in the Cloud… right?
Now, cloud services take care of themselves don’t they, so what could possibly go wrong? Of course, cloud services never get hacked or breached, do they? (Ashley Madison, British Airways, Talk Talk…)
What we need to do is get a degree of control over these services. If we have the control, then we can ensure that passwords for these services are not held in the service (and that gives us single sign-on, too). In order to access the service(s), we can insist that the user does a sign-in to our service first.
By putting Azure Active Directory at the heart of the cloud environment we can gain that control.
A user must sign-in to Azure AD before accessing any of the more than 1.3 million applications that support Azure AD for authentication. Access can be granted to only those applications that the user is supposed to have access to.
Now all we have to do is control the administration of the services.
If we can link these services together then we should be able to reduce the administration to a single point, Azure AD.
Of course, this is possible using a variety of methods. Probably the best method for doing this is to use the System for Cross-domain Identity Management (SCIM), but that will only work if the service supports it. Some services (Salesforce for example) have a direct connection to Azure and so that can also be an option.
To make these work, an account has to be created in the Azure AD with the right entitlements or group memberships.
Now all we have to do is manage the provisioning into Azure AD. Ideally, we should be able to use something like an HR system to trigger the provisioning of an Azure AD account and then use that to provision onward to the other systems.
Linking to an HR system means we are in a position to control the full joiner, mover and leaver (JML) process. New starters can be provisioned ahead of their actual start date but only enabled on their first day.
When they change departments or role, their access can be automatically modified to fit their new role. As a leaver, their access to all of the services can be curtailed on their last day ensuring that any potential data access is removed.
At ThirdSpace, we have been working with traditional identity management for many years, taking information from authoritative sources and provisioning accounts. Looking at the description of cloud provisioning above, it seems very familiar.
If we look at this new way of controlling access, we can summarise it in a few bullet points:
Again, very familiar. In fact, it is the basis of an identity strategy that we have been deploying using Microsoft technologies since Microsoft Identity Integration Server (MIIS) (and before).
Discover how Azure AD can secure your internal and external identities - and provide seamless access to all your applications and data. You'll learn how to:
Well, let’s take a look at what an identity strategy is:
This really means that what we are trying to do is manage the complete identity life-cycle. Not just the cloud-based services, but also those used on-premises.
When the overall strategy has been defined, a set of tactics can then be used to produce the long-term goal. Ideally, your strategy will be to:
“Provision accounts for staff to directory and application services appropriate for the user’s requirements; available for the start of their working life; updated to correctly identify the access through their working life and remove their access at the end of their working life.”
First though, we need to understand the flow of identity.
With this identified, we can start to define the tactical elements to be something like:
These tactics could form the stages of a deployment project, but there are other elements that should underpin the strategy. This could be defining the preferred access methods for new services, the availability of these new services to support automatic provisioning and single sign-on.
With new applications that are being written internally, a standard framework for authentication should be developed and published to ensure that any new application can use the same provisioning and access techniques as it is developed. This can reduce the development time and the support requirements while ensuring that the user experience is consistent.
In the field of identity and access management (IAM), we have so far only really discussed identity. The access management is also important. Who should have access to what?
Many organisations start this by looking at their roles. The development of roles, their management and any ongoing review can only be implemented once a degree of governance is in place.
Creation of roles without an understanding of any of the processes that will be used to control and administer them is likely to fail.
Instead, the first step should be to concentrate on the initial JML process and then add in the relevant governance. This may be limited to a specific set of objectives. For example:
When this is in place and understood, the additional, fine-grained roles can be added in a controlled manner.
The foundation of this has to be the JML process.
With all this to consider, creating a set of minimum standards for future interoperability is key.
These standards could contain the following elements. Put the framework in place for future services:
And where cloud-specific services are involved:
If you have made it this far, you will be glad to hear that you are close to the end. To summarise, there are a few things to note:
There is no cloud identity strategy.
There is no on-premises identity strategy.
When this is being defined it needs to cover the complete lifecycle and environments:
Then, when considering the implementation, it should be broken down into smaller, identifiable, quantifiable tactical deployments.
To find out more about the advantages of moving your identity management into the cloud, watch our recent webinar on-demand to discover why Azure AD is the only cloud identity provider you’ll ever need.
Alternatively, if you’d like support in putting your identity strategy together and getting it implemented, get in touch with us today.
Simply request a free Vision Call. We can help you with solution ideas, technology education, best practice advice and more.Request Vision Call
Eight-time winner of the Microsoft Partner of the Year Award for Identity Management, Enterprise Mobility, and Security and Compliance.
You are seeing this because you are using a browser that is not supported. The ThirdSpace website is built using modern technology and standards. We recommend upgrading your browser with one of the following to properly view our website:Windows
Please note that this is not an exhaustive list of browsers. We also do not intend to recommend a particular manufacturer's browser over another's; only to suggest upgrading to a browser version that is compliant with current standards to give you the best and most secure browsing experience.