Symantec IGA

Does anyone have any comments or suggestions on approaches to extracting key attributes from all IM directory global users to an integration layer.  This is being done so that a comparison can be run against a similar extract from a source system (two actually) to determine delta records for a bulk load?  I know I can execute a single LDAP query for cn=* that executes on my laptop in under two minutes with all the required attributes for about 220k global users.  Performance wouldn't be a concern.

This seems like a workable solution to me, but we are being challenged by architecture team suggestions that they don't want the integration layer (Informatica in this case) to make direct LDAP queries.  We could possibly write a simply web service and expose it on an API GW that also exists in the IAM solution, but the same architecture team is pushing back on the API GW actually implementing an API vs. simply providing a security layer in front of a web service/API that an application exposes.

I don't think IAM itself offers any such web service (TEWS???) that would be suitable.  I'm less certain if one could be authored.  Of course anything is possible.  Something could be written and hosted on the IAM servers, but is there an actual construct intended for this within IAM?

Any other thoughts on the method of extract?  Or even the practice of unloading the entire directory for delta determination?  Anyone done the same? 

Thanks.

Which user store are you trying to pull the data from? The Provisioning Directory, or the Corporate Directory.

The most practical solution is the direct LDAP query. Are there specific concerns that the architecture team has with this approach?

Hi William.  The Corporate Directory.  Identity Manager I believe.  I'm not 100% clear on the objection from our ESB team. It is something about LDAP having a single point of entry and not every application going direct. However, I wonder if this is being confused with other integrations that should be prevented from going direct and not an integration that is actually going through the ESB, which is indeed acting as that single point of entry.  I am not sure.

There is some consideration of authoring a service hosted on an internal API GW.  The GW already does indeed  an authentication web service that calls CA directory via LDAP - so perhaps the belief is that this extract should also be via the GW.  However, we also have an architecture team stating the the GW itself should not be implementing a web service, but only provide a security layer to a back end web service.  The two are at odds. :-)

Hello,

Probably need some clarification on the architecture and purpose.

Understanding the IM directory global users data storage is under LDAP server, the client would process kind of ldap requests in any way.

So questions are :

1- which are the other data sources you wish to compare to and which are the format they can export data to ?

2- which way you are thinking to process the delta comparison ?

3- what is the integration layer purpose in this process ?

best regards

Hi.

1. Two file based systems of record.  An extract from Workday and a dump of data from a payroll provider.

2. Informatica.  I'm do not know Informatica, but I can envision a SQL like approach having loaded two sources and one target data dumps into a table structure.

3. To determine what bulk load records (Create, Modify, Rehire) need to be submitted to the IAM bulk load file process to bring the target (IAM) into sync with the two sources.  Any users not in IAM need to be created.  Any users active in IAM but not in source need to be terminated.  Any differences in various attributes associated with the users that differ between source and target are made consistent with the source.

The latest approach the architecture team is investigating in order to avoid the Informatica to LDAP connector method, is to investigate whether the IM directory data can be pulled from an existing IM database table, or if IM can be customized to populate and integration table with the data required. 

I wouldn't object to such an integration if it is made possible without significant cost or complexity in the customization, if required, or the data dictionary and schema being available to the developers for straight forward SQL extract.

Thoughts? 

The architecture team is indicating the LDAP connector is not intended to be used for the high volume of records (220k) and is not an ETL technology.  I'm not sure if the latter is a general statement regarding Informatica LDAP connector, LDAP in general or just from a company standards perspective.

Hello,

The IM directory data storage is usually LDAP server but can be SQL server.

The decision is done when creating the IM Directory and cannot be changed later.

Its purpose is to store Managed Objects (Users, Groups, Organization) information.

The IM database tables are stored within SQL servers (Oracle or Microsoft). These are created during IM installation.

Their purposes are to store IM objects (Roles, Tasks, Policies,...) definitions, Running status (tasks, events, workflows) and reports definition.

The main point to be able to compare data is that the data format from the different sources should be similar.

Here it appears data are either in ldif format either in table row format.

This let guess you will need a conversion process to be done from a side or another.

You can (for example) implement an SQL endpoint in IM to store information within your own table(s) and assigned to all the IM Users template that will create the records within.

However these will be redundant data with the IM Directory ldap.

best regards.