Which version are you on?   

It is possible in the catalog to see the relationship between a permission and an account as you've shown, but you _have_ to do it from the account object.  The permission object won't show you the holders of itself.  Note that the # Users column on permissions is referring to the count of identities that are either directly assigned to a permission or that are assigned through a account.  You can also use a governance insight query to show permission holders(account) as opposed to permission holders(user/idenitty).  That is a good method for seeing if your collection to pull in perms and link them to accounts worked, rather than relying on the catalog.

The model you are trying to create is correct - accounts should map back to identities/users and permissions should map to the account.   In your CSV file it looks like multiple values are delimited by a comma.  This means the whole value for list_of_users must have a set of quotes around it, so the CSV collector parser knows that is to be treated as a set of multivalues.  You don't need to use brackets or convert to an array or anything.  If your delimeters and the quote character are set in the config to match what the CSV is doing you should be fine.  And since your accounts seem to link fine, I think that is all working.

I *think* the issue you are having is the account objects aren't mapping to identities?  That's why the permissions appear to have 0 users/identities.

I think you are pretty close to a working collector.   If you look at an identity that should have an account, is that shown in the catalog?  The AAB_Test account you show here doesn't have an identity tab, so he's not linked to anything.  That may be the problem.

--Jim

Hi Jim!

Thanks for the very detailed answer!

I was aware the #users refers to the linked identities/users, and this is working in my setup as expected.

I only was unsure, if IG would provide a permission to user mapping as well, but as you wrote, this is not the case.

Finally, I am ending with a kind of top/down view showing all accounts and permissions linked to the user/identity!

I believe you are right according to the detection of multiple values (in this case accounts), when working with a CSV collector. In my case, I am working with a modified REST collector, which receives a CSV from the REST API for the given field. If I take this value as it comes along, the accounts are not linked with the permissions, and there is an error for each entry providing a value for this field. No matter if it contains only one value or a list of values.

Using the transformation script of the field, I simply wrap the value this way:

outputValue = '[' + inputValue + ']'

after defining this "script" the collection/publication is working as expected!

I am now considering adding the transformation to the getRestRessurce() function.

Kind regards

Thorsten

Ahhh, I didn't understand this was a REST collector, and then it parsed a CSV response payload from the API.   What a gross API response!

I'm glad you got it working -- how are you changing the source of the REST collector?   Is the REST collector source in the SDK?   I've built a few collectors from the SDK in the past, but I didn't know the REST collector could be modified.

--Jim

Hi Jim,

Just to clarify: The Collector parses a JSON payload, but the corresponding data field/element is presented by the API as a csv string.

I use a modified REST GitHub collector for this purpose, but I guess I have to get back a little bit and start working with the collectors SDK, maybe.

Du you know, if it is possible to define a kind of variable in the JSON code of a collector template, and refer to this variable in a ECMAScript called to parse the data? In the collector I am using there is the function getRestResponse() which can be called with three parameters - which are definable in the collector JSON code. I am wondering if it is possible to define even more parameters/variables - or does this need the collector java class to be updated or a new class to add to the IG instance?

Kind regards

Thorsten 

Ok, I think I understand better.   This is a Github collector, but the list_of_users you received was a string separated by commas.  So you created a transform to append brackets ("[","]") to that attribute, and now the collector treats it like a set of users as you intended.

If you have it working, I would not suggest a custom collector using the SDK.  The SDK is great if there is a API you need to integrate with or if there is some business logic you need to add before IG processes the result.

In the JSON template for a collector, you essentially are building the views in the configuration.  You specify the data types and which attributes from the source map to IG attributes in the target object type (identity/account/permission).  You also specify how the references work between objects (think of manager or permission to account mappings).  So the JSON template is a way to setup how the configuration interface looks for a collector, and what the default values in there look like.

So, you could use a template to add a attribute or two, and then you could have a transform on that attribute in the actual confirm when you make an instance of that collector.

I've downloaded the REST-GitHub-Repository-Permission template, and I see the java-script view parameter that includes a getRestResource function with three params.  I think this is what you are referring to -- I hadn't seen this before!   I do think you could customize this function as needed, however I don't see where it's called, so at the moment I'm assuming its called by the collector class in the jar when the collection service is started. I think you were thinking this too.   I don't think changing the signature of this function (changing the number or type of parameters) would work if this is used by the collector service class.    

Updating the jar/java classes would be necessary in this case.   This is a pretty neat trick of having javascript in the configuration used by the static code.

--Jim

Oh, this connector is pretty neat.   Basically everything it does is in that javascript function.  I think the trick in customizing that would be to ensure what you are returning is will map to one of the object types IG supports (identity/account/permission).  Thanks for asking about that here in the forum, I might have never looked at it!

--Jim