Most IGA platforms follow a similar deployment model, which can be described as ‘hub and spoke’. 

Essentially, the IGA system sits ‘in the middle’, receiving updates from the authoritative sources and 

pushing updates out to other connected applications.  

 

However there are some nuances between different platforms. Some are cloud based, some on-

premise, some are standards based while others are proprietary. 

 

In this chapter we review a typical deployment pattern and talk through some of the differences 

which you should consider when choosing an IGA solution. 

 

Typical IGA Deployment

The diagram shows a typical IGA deployment. Below, we describe what each of the core components 

are. 

 

Component	Description
1 – Authoritative Source	The authoritative source (usually the HR Application) holds the core  information about users that drives the identity management system.  Usually data from the authoritative source is synchronised into the IGA  system, where logic or ‘business rules’ are processed to work out what  access to provision.
2 – IGA Mastered Users	Usually you can also create and manage users directly in the IGA  system. This is useful for types of user which do not have an  authoritative source – for example external users like contractors.
3 – The IGA System	The IGA system itself sits conceptually in the middle, acting as the hub  between the various connected source and target applications. In this  example we can see that identity data flows from the HR system, into  the IGA system and then onwards to various connected applications.  The IGA system acts as the ‘brain’, able to make access decisions based  upon the data received from the authoritative source.
4 – Source Connector	Usually, some kind of connector is required to synchronise data from  the authoritative source to the IGA system. Most IGA systems will have  connectors available for common HR platforms such as ADP or Bamboo.  Failing that, connection is typically via a REST API if the HR application  provides one.
5 – Directory Connector	In most IGA deployments, one of the core aims of the project is to  manage user accounts in a directory such as Active Directory. Another  connector is required to do this, typically via LDAP. More modern

	directory services are now starting to support SCIM, a REST based  standard, as an alternative to LDAP.
6 – Cloud Connector	For provisioning to Cloud applications, connectors are required for each  application. More and more cloud vendors are supporting SCIM, which  provides a standard way to provision and manage identities, but still  adoption is relatively low. Until adoption picks up, most IGA vendors  provide out of the box connectors for popular SaaS applications like  Office365 and Google Apps.
7 – On-premise  Connector	Whilst many companies are moving towards the cloud, most still have a  number of on-premise, legacy applications which they need to manage.  The IGA system needs to provide connectors with the flexibility to  connect to these applications – ideally supporting JDBC, LDAP, CSV as  methods to integrate which covers most scenarios.

 

Cloud, on-premise or hybrid

 

As we all know there is a definite trend towards cloud for all types of applications, and IGA is no 

exception. Cloud is a good choice for most scenarios, but there are a few factors to consider: 

 

1-Data Protection – if you are storing Personal Identifiable Information about your users 

or customers, you have responsibilities in most countries, and in particular in Europe 

under GDPR. Make sure that your cloud IGA vendor hosts data in a location and with 

the protections required to align regulation or legislation you face. 

 

2-Custom requirements – as a rule of thumb, you should stay away from customisation 

to keep your deployment simple and quick. However if you have specialist 

requirements which are likely to require custom work, you are less likely to be able to 

do it in a pure cloud environment. 

 

3-If the majority of your applications are on premise, particularly if they need legacy 

integration (e.g. via JDBC or text files) then a pure cloud deployment may make 

things difficult. You may want to consider a fully on-premise deployment, or 

preferably a half-way house whereby you can place one or more connectors on 

premise to handle your on-premise integrations, with everything else in the cloud. If 

you go down that route, make sure your network and security policies are friendly to 

this kind of layout. 

 

Standards vs. Proprietary 

SCIM is a developing standard in the IGA space, providing a REST based protocol for sharing and 

transporting identities between applications. Although SCIM is onto its second version, adoption is 

still slow – we are probably 5-10 years away from pervasive deployment. 

 

Many IGA systems have a highly proprietary approach to their connectors, meaning it is difficult to 

switch vendors or interoperate without a lot of development or custom work. 

 

With this in mind, it makes sense to look for an IGA vendor which supports SCIM and other 

standards, and has a commitment to incorporating standards into the platform. But you also need 

the flexibility to support other integration methods recognising that in the here and now, SCIM isn’t 

there yet. 

Comments

0 comments

Please sign in to leave a comment.