Migration of SaaS extensions on PaaS from OCI-Classic to OCI - Best practices and tips.

August 31, 2019 | 4 minute read
Text Size 100%:

Introduction

Oracle Cloud Infrastructure (OCI)  is the latest cloud infrastructure that is the strategic foundation for Oracle PaaS and SaaS offerings. Customers who are are on OCI-Classic (formerly known as Oracle Public Cloud or OPC) are encouraged to migrate to OCI as soon as possible, in order to leverage its modern capabilities as well as to take the latest releases and features of PaaS offerings on OCI. This post highlights some tips and best practices relevant for customers using SaaS extensions on OCI classic.While there are numerous differences at infrastructure level, let's look at the ones that matter for SaaS extensions. 

Identity Cloud service (IDCS)

PaaS offerings on OCI-C were supported by SIM as identity provider. While customers had some control over SIM, most tasks such as configuring federation between SaaS and PaaS or creating new instances identity providers were done by Oracle at the time of provisioning or later by Oracle through support tickets. In OCI, customers must use IDCS as identity provider. Customers have better control over IDCS. They can create new instances (stripes) of IDCS and configure federation with their SaaS instances. Typically, customer manages PaaS and administrative users in primary IDCS and creates one additional IDCS foundation instance for each environment to federate with corresponding SaaS instances in that environment.  Users and role assignments can be synchronized from SaaS instances to IDCS using ESS job or using IDCS REST API. Refer to documentation for more information. 

OCI tenancy vs. Identity domains 

The concept of identity domains does not apply in OCI. All OCI customers have single cloud account and associated OCI tenancy. Customer can be granted entitlements to provision services in one or more OCI regions. Customer has the choice to organize services and resources into compartments and restrict access to OCI resources through OCI IAM security policies.  Services in OCI must be named to be unique in tenancy, where as services only needed to be unique within a Identity domain in OCI-C. 

Security options

OCI cloud accounts have a primary IDCS that is pre-federated with OCI's IAM.  OCI's IAM has a compartment-based security model supported by OCI IAM policies.  The access control for 'My services' console is managed in primary IDCS.  The service entitlements in 'My services' are managed as permissions in IDCS applications. Then, once provisioned, each PaaS offering opens up other possibilities for additional control. For example, JCS can use variety of identity providers and DBaaS manage users inside a Oracle database. Customers should keep these layers of security in mind as they determine their OCI security architecture. Typically all of these layers play a role in securing a cloud solution. Refer to OCI and PaaS documentation.  Here is summary of categories of security :

  • PaaS Life cycle management - Each platform service administrator provisions and manages PaaS instances, with admin access to features of the PaaS service (JCS, SOACS, OACS)

  • PaaS Access management - Teams access features of a PaaS service in tiers (Administrator, Developer, Deployer, User, Monitor, etc)

  • OCI Life cycle management - PSM service or administrators Create or modify OCI objects such as Network, Storage and Databases

  • OCI Service Access Management - Access features of a OCI object or modify a OCI object, such as Compute or database

PSM and ManagedPaaSCompartment

PSM is a component invisible to customers that manages provisioning and updates of most PaaS services. PSM's capabilities are used by customers from 'My services' pages. In OCI, there is a compartment named 'ManagedPaaSCompartment' pre-configured for use by PSM. All PaaS services created from 'My Services' console are provisioned inside this compartment. Customer can not create or alter resources directly in this compartment.  Note that this applies only to resources created by PSM. There can be other services such as DBaaS instances and network subnets in other compartments used by PaaS instances. 

Regions and Availability domains

This is another key difference between OCI and OCI-C. Regions are distinct large metro areas and availability domains are separate data center locations within a region. customers now have the choice of creating highly available services that's spread across multiple AD with in region. 

Networking

OCI's networking architecture is more sophisticated compare to OCI-C.  There's no concept of shared networks in OCI. Customers can configure one or more VCN and divide each VCN into multiple subnets located in specific availability domains. By default instances within a subnet  or in different subnets can not communicate with each other. OCI security lists control how these communications.  OCI route tables control how subnets in OCI communicate with outside world. Customers will need to think carefully about VCN/subnet/Security list design.  The design choices can range from relatively flat network with fewer security polices to a network split by environments and types of services associated with specific security lists. Customer requirements and internal organization are key to determining a network design.

VPN configuration is much easier and fully self-service in OCI. VPN connections can be established as little as an hour. Fast connect configuration  and procedures are largely similar to that of OCI-C. 

Geographical locations

As customers migrate to OCI, they might find that some of their services, such as Fusion SaaS applications, remain in a legacy OPC data center and the migrated PaaS service is in another OCI region. This scenario will be less likely as more services adapt OCI. Traffic between OCI regions and legacy data centers are over network backbones managed by Oracle. Cross-region network latency is manageable with careful design of integrations between applications. For example, combing or bulking more data into to SOAP or REST requests will reduce number of network round trips and make integrations less chatty.

New releases and features

OCI is the strategic cloud infrastructure offering where most of the new services offerings and most new capabilities of prevailing PaaS services are introduced. Services OCI-C receive fewer new features compare to OCI. While OCI-C is supported, customers will be able to exploit the full potential of the next generation cloud by migrating to OCI.  

References

IDCS documentation:

https://docs.oracle.com/en/cloud/paas/identity-cloud/index.html

OCI documentation: 

https://docs.cloud.oracle.com/iaas/Content/home.htm

Configure IDCS as identity provider for JCS:

https://docs.oracle.com/middleware/12213/wls/SECMG/identity-cloud_atn.htm#SECMG-GUID-45EE08AE-1073-46D5-82EB-174AD6BADE0C

Enable federation between IDCS and JCS: 

https://blogs.oracle.com/blogbypuneeth/steps-to-configure-saml-20-with-oracle-saas-as-idp-and-oracle-java-cloud-service-as-sp

SaaS to IDCS synchronization: 

https://docs.oracle.com/en/solutions/create-approval-process-digital-assets/synchronize-oracle-fusion-applications-cloud-service-user-identities-and-roles-oracle-identity-cloud1.html#GUID-611F888F-8BDE-4240-BBF3-D315DBA68DEF

 

 

Mani Krishnan


Previous Post

Deploying Remote Data Gateway in a Private Subnet

Dayne Carley | 1 min read

Next Post


Service Callouts in API Platform

Andy Knight | 3 min read