Introduction
Cloud migration is a vast topic. In this blog we focus on migrating Identity and Access Management (IAM) systems and processes, which, in many cases, comprise the early stages of a company’s journey to the cloud.
Benefits of Cloud Migration
Cloud adoption has become integral to an enterprise’s Information technology (IT) modernization. Running your organization on cloud-based applications presents some key benefits including:
Increased Business Agility
Resources are available on demand, and you can switch vendors for the same types of applications, if necessary.
Lower Business Risks
You don’t have to buy packaged software that may end up being discontinued by the vendor and eventually become obsolete.
Optimized Operational Costs
You pay for always up-to-date applications and services as you go, based on your specific use of the products.
Improved Security
Responsibility is shared between three parties:
- the cloud platform vendor providing infrastructure-as-a-service or IaaS, e.g. Google Cloud Platform, Amazon Web Services (AWS), or Microsoft Azure
- the cloud application vendor providing software-as-a-service, or SaaS, e.g. Salesforce, Workday, and Okta, a market-leading IAM service
- your IT department, responsible for ensuring that both your IaaS and SaaS layers provide your employees and customers with secure and frictionless access to your company’s applications
Adopting cloud infrastructure and cloud services is a continuous process and companies can start reaping the benefits from cloud technologies while continuing to run enterprise applications on their existing environments. If well-planned and coordinated, the process of migrating resources to the cloud is non-disruptive, seamless, and secure.
One of the main concerns regarding cloud migration is security, which is why we see many companies embracing IAM as a cloud service early in their IT transformation journey.
An IAM service is basically designed to restrict enterprise applications access to users or services that are securely authenticated (i.e., proving who they are based on their credentials such as username and password, biometrics, or software and hardware security tokens), and are duly authorized (i.e., proving what they can do once authenticated, based on their assigned roles and entitlements).
Migrating Your On-Premises IAM to a Cloud-Based IAM Service
On-premises IAM systems often present the drawbacks mentioned earlier. That is, heavy initial investment in packaged software acquisition, and high cost to operate and maintain.
Migrating your existing legacy IAM system to a cloud-based solution is completely independent of how you run your existing portfolio of enterprise applications.
The following five sections present a practical approach to a seamless transition of your current IAM system to the cloud.
1. Initial Discovery
- Legacy IAM Product
- Logging system, network deployment (proxies, load balancers, web applications firewall (WAF), etc.), and back-up system.
- Policies (authentication, authorization, user life cycle management).
- User population types (e.g., employees or customers) along with their number and the user agents supported (e.g., web browser, native mobile apps).
- Types of applications (identify and categorize applications, e.g., based on the industry standards they support).
- Applications requiring (federated) single sign-on (SSO) whereby a user can access applications in different identity domains without being challenged to re-authenticate to access each application.
- Applications integration and user provisioning, including source and destination of user migration, user life cycle management based on Create, Read, Update, Delete (CRUD) operations.
- Source of truth (e.g., Human Resources system, Microsoft Active Directory, a relational database, etc.), which stores and maintains the authoritative (initial) user profiles.
2. Initial Cloud-Based IAM Configuration
- Install external components where necessary (typically agents or reverse proxies necessary for communication between your applications and the cloud-based IAM system).
- Define IAM user groups (based on users’ roles and entitlements and the rules to be applied to each group).
- Define initial authentication schemes with password policies based on your company’s governance guidelines.
- Define step-up authentication if required, selecting the most appropriate step-up authentication factor (SMS, email, software or hardware token, biometrics).
- Test user population with small user samples or fictitious users.
3. Integration of your Legacy IAM with your Cloud-Based IAM
- User migration (from your legacy system to cloud).
- Federated SSO configuration so that your legacy IAM system can communicate with your cloud-based IAM system. In this case, we rely on industry standards such as Security Assertions Markup Language (SAML) or OpenID Connect (OIDC) and OAuth, OIDC’s underlying delegated authorization protocol.
- Integration testing with a user sample.
4. Application Migration to your Cloud-Based IAM System
- Identify priorities (which applications should be migrated first).
- Identify and categorize your integration approach (e.g., SAML, OIDC/OAuth, header-based authentication, or Kerberos).
- Select which applications will require external components, e.g., header-based applications will require the use of a reverse proxy to translate communication from the cloud-based IAM system which relies on industry standards and your applications, which may not.
- Test all application migrations.
5. Disconnect your Legacy IAM System
- Make necessary back-ups.
- Deactivate federated SSO between your cloud-based IAM system and your legacy IAM system.
Start Your Cloud Migration Journey
If you feel that you may not have all the technical resources necessary to tackle all the tasks suggested above, or you’re under a tight time constraint, professional cloud consulting services organizations such as BeyondID can help you from project inception to completion, and ensure that your journey to the cloud successfully progresses on schedule and within budget.
