A major decision for all software deployments, including Identity Governance and Administration (IGA) deployments, is what platform to deploy to; cloud, on-premise or a hybrid of the two. Many IGA products are available as both cloud-based and on-prem. Some on-prem products can be hosted as SaaS or managed service offerings in the cloud. Some of the newer IGA products are “born on the cloud” and have no on-prem option. There are many non-functional considerations of cloud vs. on-prem, such as installation and maintenance of servers and operating systems, and the dynamic scalability that the cloud offers. These will be relevant to an IGA project equally as any other project. 

One consideration that is unique to IGA projects is the target systems – specifically the repositories and their accounts and access that are to be managed and/or governed. It may be that the target systems will put constraints on the selection of IGA product. It is better to understand where your identity data is and how you need to manage it prior to selecting an IGA product.

This article will look at some considerations relating to “the plumbing” – what model of IGA solution is needed, what target systems are affected, and what identity data is to be managed on those systems. Then it will look at the architectural patterns that may need to be used, and how to decide which one you need.

What Model of IGA Do You Need?

There are three basic models of IGA I have encountered; read-only identity governance, read-write identity governance and read-write identity management (or mixtures of them).

Identity governance is concerned with; attestation/certification, risk management, separation of duties (SoD), auditing, reporting analytics. If your governance requirements are just to prove that you are reviewing access periodically and identifying any SoD violations, you may only need a read-only identity governance solution. 

In this model, the target systems containing the users and access are disconnected from the identity governance system; some disconnected process is used to upload accounts and access into the governance system (like importing csv files), this data is used for analysis/reporting/recertification, and any changes needed (such as revoking access) are manually applied to the target systems. 

This is a perfectly valid approach if it meets your requirements and is by far the simplest approach to an identity governance solution.

The read-write identity governance model has the identity governance system connected to the target systems via some integration (referred to as adapters or connectors, sometimes agents). This integration provides two flows; reconciliation involves pulling account and access data and pushing it into the identity governance system, provisioning involves pushing account and access changes (often access membership) back to the target system from the identity governance system.

This “plumbing” between the identity governance system and the target systems is often implemented in a flexible framework that supports multiple protocols (like LDAP, SCIM, JDBC/ODBC) and communication mechanisms (REST, SOAP, TCPIP). We also talk of agentless and agent-based connections to target systems. Agentless connections don’t need an agent deployed on the target systems and rely on a remote protocol that works across a network (or the internet). Agent-based connections require some sort of agent to be deployed on (or near) the target system as there is no agentless mechanism to access account and access data. The latter is usually required for legacy systems (e.g. mainframe) or systems with rich access control mechanisms (like SAP R/3 systems).

The read-write identity management model is focused more on the identity management capabilities, like an access catalog, access requests, birthright provisioning, workflow and entitlement policy. Whilst the focus is different to an identity governance system, it has the same read-write integration needs for target systems; reconciliation of accounts and access, and provisioning of account and access changes.

Many organizations have requirements that cross both identity management and identity governance. There are different business drivers and likely have different owners and sponsors in an organization, and this makes IGA deployments challenging. But it is entirely feasible to have an integrated identity management and identity governance solution (via a single product or an integration of products), leverage the one integration platform.

If the read-only identity governance model is all that’s required, you’re unlikely to see any constraints between cloud and on-prem IGA products; almost every product supports some batch or bulk-load mechanism. However, if you need a read-write model, then you will need to do further analysis of in-scope target systems and the identity data to be managed and see if that constrains your product options.

What Target Systems Need to be Managed?

If your IGA solution is to integrate with target systems, you need to know what they are, where they are and how you can connect to them.

Do you have SaaS applications in the cloud to connect to, and do they support some standard mechanism for identity management/governance, like SCIM? Most major SaaS applications will provide a standard interface for managing accounts and access. Do you have SaaS systems that don’t have a standard interface? Is a custom connector possible, and can it be developed (by yourself or the vendor)? Deployment of an agent to a SaaS application in the cloud is unlikely. Or can these applications be de-scoped?

Do you have on-prem applications to connect to? Do they support a standard mechanism for identity management/governance, like LDAP or JDBC? Unlike born-on-the-cloud applications that grew up with standards, many on-prem applications built their own interfaces. There are still many legacy applications that don’t provide an identity management interface and some custom integration is required to directly update datastores or perform screen-scraping against a UI.

Can these on-prem applications be managed remotely, and from outside your network? And if so, how? Do they support a HTTP-friendly protocol so you don’t need additional holes in your firewall? Do they provide an external gateway “on the edge” that you can securely connect to from a cloud IGA system? Or do they require unique ports and protocols, possibly agents deployed?

What Identity Data is to be Managed on those Target Systems?

Identity management is concerned with managing accounts (users) and access, where access may be:

• Attributes on the account – such as a flag or default access level (such as IBM z/OS RACF user profiles having default access and other flags like “OPERATOR”),
• A group the account is a member of – where these groups are tied to permissions on the target system (such as Microsoft Active Directory Groups being mapped to permissions on Microsoft Windows systems), and
• Direct mapping of accounts to permissions – whilst this is considered bad practice it is supported in many target systems (like Amazon Web Services and IBM z/OS RACF).

Traditionally Identity Management has focused on the first two; accounts with attributes, and account group membership. Direct mapping of accounts to permissions should be reserved for admin or service accounts outside the control of an Identity Management system (not always the case).

Identity Governance has shifted the focus to understanding all access to systems, the controls around managing this access, and risks associated with access. To get a complete picture of access, you may need visibility into not just the account attributes and group memberships, but also any account to permission mappings.

Some systems, like IBM z/OS RACF and SAP Application Server ABAP, have incredibly complex access models. Presenting the users and groups in the IGA system may not be sufficient to see all access a person has in these systems. Also, depending on how systems have been configured, access groups may not indicate the access they represent. In these cases, the IGA system may need to dig deeper into the access model on the target systems. This fine-grained entitlement approach is normally read-only – the permissions and the account memberships of the permissions is pulled into the IGA system for visibility, analytics, recertification and reporting. But it is rare for integration to create/modify/delete permissions on target systems – this is the realm of the system administrator.

This complex IGA data need presents a challenge to many IGA products. All products will provide management of accounts, account attributes and group memberships. Some will support consumption of target system permissions. Very few will consume and/or manage fine-grained permissions in complex systems like RACF or SAP AS. 

Many products today are standardizing on the System for Cross-domain Identity Management (SCIM, aka Simplified Cloud Identity Management). The standard implementation only supports a standard user (account) and groups, not permissions or target system-specific account schemas. There is scope to extend SCIM. Similarly, directory implementations that support LDAP often focus on accounts and groups (like using LDAP in front of an RACF system) and may not expose fine-grained permissions.

Whilst most IGA products will support accounts and groups management, if you need more you need to look to IGA products that support different schemas, have integration configured for what you need or support customization to allow you to do it yourself.

IGA Architectural Patterns for Different Target Systems

In the previous sections we have looked at the constraints around IGA you need to consider; what model (read-only IdG, read-write IdG, read-write IdM, a mix), the target systems you need to manage, and the identity data to be managed on those systems. This will dictate the architectural pattern you may need to consider for your IGA solution.

First off, if all you need is a read-only Identity Governance system, then it doesn’t matter what your solution looks like as long as it can consume account and access data in some form. It won’t matter if the IGA system is on-prem or in the cloud.

Next, if you need to manage accounts and access in a cloud target system then assuming that SaaS solution provides a web-friendly remote mechanism, then it doesn’t matter if the IGA system is on-prem or in the cloud. The secure connectivity concerns about cloud to cloud connectivity are the same as for on-prem to cloud connectivity (most organizations will have applications running on-prem that connect out to cloud services). This is shown below.

There may be a concern about accessing fine-grained access information in a cloud service, and whether specific IGA products support this, but that won’t have a bearing on whether the IGA system is hosted on-prem or in the cloud (other than the ability of IGA products to get and process fine-grained access data).

This leaves us with the last scenario – the need to manage (read-write) accounts and access in on-prem systems (potentially with the need to access fine-grained access data, but probably in a read-only mode) from either an on-prem IGA system or a cloud IGA system.

Managing on-prem targets from an on-prem IGA system should be trivial; network connectivity, use of SSL, maybe proxying across network zones. 

The challenge is when using a cloud IGA solution to manage on-prem targets. If you can access the target system via a http-friendly mechanism (web services, REST) then you only need connections over a http/s port (preferably via a reverse proxy). There are probably external systems accessing the network via this means already, so it should not represent a major issue to the IT Security team.

If not, you may need to look at one of the following:

• Using a Virtual Private Network (VPN). VPNs were popular in the early days of cloud, particularly for these one-many scenarios, but have fallen out of favor due to maintenance and issues with visibility. There are similar mechanisms to provide a secured “pipe” from cloud into an on-prem environment.
• Opening up dedicated ports in the external firewalls to allow direct connection to each target system from the cloud IGA system. This is a bad practice as it provides an increased attack surface to external parties. It’s also not scalable for deployments with many (and changing) target systems as you need to constantly manage firewall rules (which increases the risk of issues).
• Leveraging some sort of gateway on the edge of the network. This is an emerging pattern from IGA vendors. It may also be called a bridge, bus or exchange.

These options are shown below.

It is highly likely that if you’ve got legacy on-prem systems, some will not support a http-friendly integration and you need to look at one of the options above. VPNs and more firewall holes are not recommended. Some IGA vendors provide a gateway approach, where the cloud IGA system securely connects to the gateway. It might be possible to leverage an on-prem IGA system as a provisioning hub to achieve the same thing. Again, some vendors support this hybrid model. 

There are other patterns outside the scope of traditional IGA, such as deploying a cloud directory service that synchronizes with on-prem directories (like Microsoft Azure Active Directory). They may be a way to avoid the constrains of cloud IGA to on-prem target system integrations but may not solve all the plumbing problems depending on your requirements. 

Conclusion

In the previous sections we have discussed how the requirements for systems to be managed by an IGA solution might impact on the choice of a cloud, on-prem or hybrid IGA product. 

Before selecting an IGA product, you should consider the IGA model you need (now and future); a read-only identity governance solution, a read-write identity governance solution, a read-write identity management solution, or a mix of these.

You also need to consider the target systems where the accounts and access reside that need to be managed. Where are they and how can those account and access repositories be accessed? Tied to this is the amount of identity data to be managed on those systems; is users (accounts) and groups sufficient for your governance requirements, or do you need to get into fine-grained access. Can off-the-shelf integration (adapters/connectors) meet these needs or would bespoke integration need to be developed?

With an understanding of the target systems and identity data to be managed you can look at any architectural constraints they pose;

• If you only need a read-only identity governance solution, choice of cloud-based or on-prem IGA product is irrelevant; it’s all a matter of how to get account and access data to the product.
• If your target systems are all cloud and you only need to work with user and group data, then choice of cloud-based or on-prem IGA product is irrelevant; both cloud and on-prem products will have the same considerations in accessing cloud target systems. The complexity will arise if you need more than user and group data and there is no off-the-shelf integration available, and you need to develop bespoke integration. You may need to look at the products that allow this flexibility.
• If you also have to manage on-prem target systems, then choice of cloud or on-prem IGA product will need more consideration. On-prem IGA systems will be able to access on-prem target systems (with appropriate network connectivity and security). However, cloud IGA systems will need to connect into the network to talk to on-prem target systems. This may dictate the need for a VPN, opening up more firewall ports and use of an on-prem gateway to proxy connections. This may represent a constraint on the choice of IGA product.

It is important to understand what you are managing prior to deciding on cloud, on-prem or hybrid and choosing an IGA product. Failure to do so could lead to problems down the track.

This article originally appeared on 29 Jul 2019 on LinkedIn; https://www.linkedin.com/pulse/iga-cloud-on-prem-have-you-checked-plumbing-david-edwards-iamdavid-/