Design an Identity Governance Solution leveraging identity insights

Identity Access Management (IAM) is not just hype, nor is it a new phenomenon. Access control applications have been in use for several decades, and are embedded in many organizations’ infrastructure, but they are becoming increasingly difficult to manage.

Customers sometimes manage hundreds of thousands of users, who may have access to multiple applications, meaning there are potentially hundreds of thousands of possible authorizations. Authorizations such as access rights and permissions within an application, which all require maintenance. This leads to questioning who has access to which information under what context/conditions and how.

Architecture

This reference architecture leverages the following services.

  • Oracle Identity Governance (OIG)
  • Oracle Identity Role Intelligence (OIRI)
  • Oracle Access Governance (AG)
  • Oracle Access Management (OAM)
  • Oracle Cloud Infrastructure Identity and Access Management (OCI IAM)

This architecture can be implemented in Oracle Cloud Infrastructure (OCI), customer data centers, or third-party clouds. Some of the benefits of leveraging this architecture include:

  • Reduces operation costs for user access provisioning by eliminating redundant and time-consuming manual processes.
  • Achieves a reasonable return on investment by investing in new technologies such as containers and microservices
  • Minimizes security risks by deploying effective controls and eliminating human error
  • Consolidates access data into one view to provide insight into who has access to what areas, and how risky that access is to the organization. This view provides security owners and managers total visibility into user access patterns.
  • Increases productivity and end-user satisfaction by leveraging an out-of-the-box intuitive dashboard.
  • Automates regulated compliance reporting.

Logical Architecture

The following diagram illustrates the target IAM reference architecture.



identity-governance-logical-architecture.zip

The capabilities of each component implemented by the Oracle platform follow.

Oracle Identity Governance (OIG), Oracle Identity Role Intelligence (OIRI), and OIG Connectors provide the following.

  • Administration

    Self-service features and delegating administrative functions for management of user identity, including user and privileged accounts.

  • Provisioning

    The outward flow of user information from a central administration point to a target system. Track all actions (such as creation, updates, and deletion) of accounts, roles, and entitlements across all managed resources.

  • Reconciliation

    The inward flow of user information from a trusted system or target system. User information typically includes all actions (such as creation, updates, and deletion) of accounts, roles, and entitlements to the central administration platform.

  • Workflow Management

    The ability to automate business and IT processes to enable policy-based automated provisioning and modeling of approval processes for managing resource access requests.

  • Password Management

    Password policy support and self-service administration for password resets and password changes.

  • Notifications

    Routing of information pertaining to all types of events handled by the platform towards the end-user and to the management of relevant units, as well as system, security, and delegated administrators.

  • Connectors

    Three-tier integration capability to various heterogeneous identity-aware IT systems. This three-tier capability reflects the aim to minimize custom development, maximize the reuse of code, and reduce deployment time.

  • Rules Engine

    Defines evaluation criteria for the execution of processes related to users, roles, entitlements, accounts, and organization management.

  • Segregation of Duty

    Use of Identity Audit (thereof IDA) to define and detect violations. The detection mechanism of IDA monitors users' actual access to resources and captures any violations on a continuous basis. IDA has two modes: detective and preventive.

  • Delegated Role and Access Management

    Logical grouping of users to whom you can assign access rights, provision resources automatically, or use in common tasks such as approval and access certification.

  • Risk Analytics

    Comprehensive risk management capability for all critical functionalities that can directly assign high, medium, and low-risk levels to roles, accounts, and entitlements.

  • Role Intelligence and Mining (OIRI)

    Discovery of entitlement patterns across peer groups, with support for a top-down approach for role mining based on user attributes. A bottom-up approach that filters data based on applications and entitlements, or a hybrid top-down bottom-up approach.

    Comparison of candidate roles with an existing role to avoid role explosion. Ability to fine-tune the candidate roles based on user affinity and role affinity. Automated publishing of roles to OIG to trigger a workflow for role adoption. Ability to merge data from different sources, such as OIG database and flat files, and provide what-if analysis before moving candidate roles to production.

Access Governance (AG) and AG agent provide the following.

  • Execution of certification campaigns with an intuitive user experience, to help ensure appropriate and timely access reviews. The intelligent workflow guides users and makes straightforward suggestions to help meet compliance and regulatory objectives faster.
  • Machine learning-based insights risk scoring and advanced analytics with prescriptive recommendations to improve risk awareness, reduce manual certification efforts, and automate access control/provisioning.
  • Consolidation of group access data into one view that details who has access to what, and how risky that access is to the organization.
  • Identity data orchestration to pull entitlement data directly from Oracle Identity Governance and trigger remediation.

Oracle Access Manager (thereof OAM) and OAM WebGate provide the following.

  • Authorization involving real-time access policy decisions and enforcement (based on identities, attributes, roles, rules, and entitlements for the solution interfaces).
  • Authentication using real-time verification against Active Directory/Azure Active Directory user repositories of claimed identities for the solution interfaces.
  • Federated Single Sign On, in the role of Identity Provider with OCI IAM in the role of Service Provider for the solution interfaces.
OCI IAM provides the following.
  • Federated SSO with OAM, as Service Provider with OAM acting as Identity Provider.

Target Applications

Integration target applications to implement include some of the following.

  • Identity Reconciliation: Peoplesoft, SAP HRMS, Oracle e-Business Suite HRMS
  • Provisioning and Target Reconciliation: SAP, Siebel, Salesforce, ServiceNow, Oracle e-Business Suite, Microsoft Office 365, Azure Active Directory, Amazon Web Services.

Physical Topology

The following diagram illustrates the reference architecture of a Kubernetes cluster in an Oracle Cloud Infrastructure region that contains multiple availability domains. A Disaster Recovery Strategy within the same region is recommended, to take advantage of multiple availability domains (data centers) while minimizing latency and performance degradation. The proposed topology utilizes two out of the three availability domains, due to the recommendation that all pods should run on workers nodes in the same availability domain. More details on the Disaster Recovery Strategy are provided below.



identity-governance-topology.zip

The architecture has the following components:

  • Virtual cloud network (VCN) and subnets

    A VCN is a customizable, software-defined network that you set up in an Oracle Cloud Infrastructure region. Like traditional data center networks, VCNs give you complete control over your network environment. A VCN can have multiple non-overlapping CIDR blocks that you can change after you create the VCN. You can segment a VCN into subnets, which can be scoped to a region or to an availability domain. Each subnet consists of a contiguous range of addresses that don't overlap with the other subnets in the VCN. You can change the size of a subnet after creation. A subnet can be public or private.

  • Region

    An Oracle Cloud Infrastructure region is a localized geographic area that contains one or more data centers, called availability domains. Regions are independent of other regions, and vast distances can separate them (across countries or even continents).

  • Internet gateway

    The internet gateway allows traffic between the public subnets in a VCN and the public internet.

  • Web Application Firewall (WAF)

    Oracle Cloud Infrastructure Web Application Firewall (WAF) is a payment card industry (PCI) compliant, regional-based and edge enforcement service that is attached to an enforcement point, such as a load balancer or a web application domain name. WAF protects applications from malicious and unwanted internet traffic. WAF can protect any internet facing endpoint, providing consistent rule enforcement across a customer's applications.

  • Dynamic routing gateway (DRG)

    The DRG is a virtual router that provides a path for private network traffic between VCNs in the same region, between a VCN and a network outside the region, such as a VCN in another Oracle Cloud Infrastructure region, an on-premises network, or a network in another cloud provider.

  • Service gateway

    The service gateway provides access from a VCN to other services, such as Oracle Cloud Infrastructure Object Storage. The traffic from the VCN to the Oracle service travels over the Oracle network fabric and never traverses the internet.

  • Network address translation (NAT) gateway

    A NAT gateway enables private resources in a VCN to access hosts on the internet, without exposing those resources to incoming internet connections.

  • Subnets
    The VCN in this architecture consists of 10 subnets pairing production and disaster recovery environments. All subnets are availability domain-specific, meaning they are limited within one data center to minimize latency and performance degradation. Disaster Recovery deployed in the same VCN and region also protects against availability-domain failure.
    • Two public subnets are for the web tier.
    • Two private subnets for the private load balancer.
    • Two private subnets are for admin hosts that contain the tooling necessary to manage the Kubernetes cluster and the nodes of the Kubernetes cluster.
    • Two private subnets are for the Kubernetes cluster API endpoints.
    • Two private subnets are for Autonomous Database private endpoint access to only allow connections from the specified private network (VCN).
  • Load Balancer Nodes
    • One regional public load balancer node intercepts and distributes traffic to the compute instances running the web tier of the solution across production and disaster recovery environments.
    • One availability domain-specific private load balancer node, per environment, intercepts and distributes traffic to the Kubernetes nodes running the containerized applications middle tier.
  • Kubernetes Worker Nodes

    The Kubernetes worker nodes are the compute instances on which containerized applications are deployed. All the worker nodes in this reference architecture are in a single node pool, and attached to a private subnet. Multiple node pools can be created if required.

    The worker nodes in this reference architecture are not accessible directly from the public internet. Users of the containerized applications can access them through the load balancer. Administrators can access the worker nodes through the bastion service. The Kubernetes master nodes run in Oracle's tenancy and are not shown.

  • Kubernetes API Endpoint

    The Kubernetes API endpoint, on the cluster control panel hosted in dedicated subnet, enables end users to query and manipulate Kubernetes resources (such as pods, namespaces, config maps, and events).

  • Pods/Services Overlay Network

    The Kubernetes networking model assumes pods have unique and routable IP addresses within a cluster. In the Kubernetes networking model, pods use those IP addresses to communicate with each other. With the cluster's control plane nodes with pods on other clusters, with other services (such as storage services), and with the internet.

  • Autonomous Database with Private Endpoint

    Provides enhanced security by setting a database property to enforce that all outgoing connections to a target host are subject to and limited by the private endpoint's egress rules. Egress rules are defined in the VCN security list, or in the Network Security Group (NSG) associated with the Autonomous Database instance private endpoint.

  • Bastion service

    Oracle Cloud Infrastructure Bastion provides restricted and time-limited secure access to resources that don't have public endpoints and that require strict resource access controls, such as bare metal and virtual machines, Oracle MySQL Database Service, Autonomous Transaction Processing (ATP), Oracle Container Engine for Kubernetes (OKE), and any other resource that allows Secure Shell Protocol (SSH) access. With Oracle Cloud Infrastructure Bastion service, you can enable access to private hosts without deploying and maintaining a jump host. In addition, you gain improved security posture with identity-based permissions and a centralized, audited, and time-bound SSH session. Oracle Cloud Infrastructure Bastion removes the need for a public IP for bastion access, eliminating the hassle and potential attack surface when providing remote access.

  • Persistent Storage Replication

    Rsync on NFS provides a method of persistent storage replication that replicates the domain configuration, with minimal maintenance and configuration.

  • Autonomous Data Guard (Data Guard Replication)

    When you enable Autonomous Data Guard with a standby database in the current region, Autonomous Database monitors the primary database and if the primary database goes down, the standby instance automatically assumes the role of the primary instance. With Autonomous Data Guard enabled with a local standby database, Autonomous Database provides an identical standby database that allows the following, depending on the state of the primary database.

    If your primary database goes down, Autonomous Data Guard converts the standby database to the primary database with minimal interruption. After failover completes, Autonomous Data Guard creates a new standby database for you.

    You can perform a switchover operation, where the primary database becomes the standby database, and the standby database becomes the primary database.

Considerations

When designing your identity governance solution, consider a disaster recovery approach.

Disaster Recovery

The Disaster Recovery solution on OCI is an active-passive model.

There is a primary system consisting of an Oracle WebLogic Domain (WLS), Oracle Identity and Access Management (OIG & OAM) on Oracle Kubernetes Engine (OKE), a load balancer, an Oracle Cloud Infrastructure Autonomous DB system (ATP), and two Oracle HTTP Servers (OHS) in one Availability Domain (AD).

The secondary system consists of the same architecture components, but in a different Availability Domain. The Availability Domain, data center, and sites are physically located far enough from the primary Availability Domain to protect the components in the event of a disaster.

Explore More

Learn more about designing an identity governance solution.

Review these additional resources:

Acknowledgments

Author: Katerina Kalimeri

Contributors: Andreas Theodoridis, Ioannis Episkopakis, Kostantinos Pateras