Creating a from scratch ICF connector

Troubleshooting
, , ,
#1

So I’m trying to develop a new connector. I do not understand some of the nuances and cannot find documentation that really deals with it. I think I have my user create method working, and I think I understand it. I am attempting to add something that will function like a group on a target resource, but I do not understand how it interfaces with IDM. This is all custom so I’m building an attribute called assignees to hold the users who are assigned to this object. should the attribute be an array? how do I tell it that in my connector schema? How do I get recent changes, say a user is added or removed from this object when a change comes in? If it’s via an assignment, is ONLY the user and the thing being assigned in the data set given to the connector? I just don’t know. Can anyone offer help?

#2

Hi @rob.kimball - there is a great two part article that should help get you started and help with wrapping your head around some of the concepts.

I suggest reading this and seeing if it helps, and then if you have more questions you can follow up here.

#3

So I’m creating an ICF connector, not a scripted connector. I’ve looked over this article and will go through it again but is there any articles on creating an ICF connector, and specifically on how creating a schema for group type objects. That is what I’m looking to understand.

#4

ICF is the Identity Connector Framework and it supports custom developed connectors both as Java connectors and as scripted connectors, so this article is on creating an ICF connector it just happens to be focused on Groovy scripted connectors. Generally speaking, I avoid custom Java connectors due to the complexity associated with them. Are you certain that you need to code your connector using Java?

#5

Until I find I can’t do it, yes. It must be a real ICF java connector. At this point I have the connection working, and I have the create (mostly) working for users. What I’m trying to understand is how to create a group like object. How does IDM process it? With a user, I have the mapping, I do a recon and I see the create is triggered and ONE row is processed. this “group” object though will have multiple “members” do I assume it expects one row entry with the user being assigned AND the “group” it’s being assigned to? or is the “group” obect expected to have a multivalued member attribute? if so how is that seen in the create method? If anyone out there has built a real connector and has time, I’d love some input. Thanks.

#6

I mean, scripted connectors are real connectors too, but that’s a discussion for another time.

Have you looked at how other connectors treat groups? Often times the group itself is the object being managed, and the group has a property representing the members of the group which is a multivalued attribute. You could also have a property on your account object representing the groups a user is a part of, of course that is dependent upon the system you are integrating with.

#7

I been through the code on github and looked at LDAP and a few others. some of the bigger connectors schema code is very tough to decipher. A of samples I find avoid the topic and just create user object classes so it’s very unclear how other object classes will be treated by the application. I am just unclear on how the “member” attribute will be treated by IDM and how I should create the schema. I was hoping someone has done this, but I guess as 99% of everyone is using OOTB connectors now, creating something from scratch is pretty rare. though I think my issue isn’t even so much connector understanding as much as just how to create the “child table” schemas or “group” schemas in any connector.

#8

Looking over the docs for the scripted connector, i think it likely i’ll have the same questions as my questions are all about how to create and manage the schema and just like most samples, the tutorial above ONLY deals with account objects

#9

Is your question then more about how to represent these group objects in IDM? From a connector standpoint it would just be an array of strings (assuming your group object’s group membership property is returning strings of user ids).

At the end of the day, there really isn’t any meaningful distinction between a user object in a connector or a group object in a connector or any object in a connector.

#10

I am creating a schema in the connector. it acts basically the same, so let’s just call it groups. It has attributes for its name, etc. and an attribute of what users is assigned to it. I see lots of examples of what a User schema looks like but not have even a basic group. I tried doing it the way I’ve been able to find inside some other OOTB connectors, (again, hard to read the source for ldap code as so vast) but a) can’t tell if it’s right, and b), in the UI the schema isn’t coming up as an array the way other multivalued attributes do in OOTB connectors. So I have no idea if I’m creating this correctly.

#11

So the UI portion of things (assuming you mean the IDM UI) is handled via the provisioner file, which maps your connector’s attributes to attributes that will be understood by IDM. An example to have the UI render as an array is this, which is found in the group object of the openicf-ldap connector:

                "uniqueMember" : {
                    "type" : "array",
                    "items" : {
                        "type" : "string",
                        "nativeType" : "string"
                    },
                    "nativeName" : "uniqueMember",
                    "nativeType" : "string"
                }

This tells IDM that the openicf-ldap connector’s group object has a property named uniqueMember ("nativeName" : "uniqueMember"), and to treat the value returned by that property as an array of strings. The openicf-ldap connector probably returns uniqueMember as List<String> or something similar (but don’t quote me on that!)

#12

so in my connector code. It’s, whatever I want really, List of strings or array of strings. but I can’t tell the connector code that it will be array type in the provisioner? I make that change in provisioner json itself?

BTW, thank you for all the responses. it is very appreciated.

One more question on this topic. I think part of my problem is trying to picture this object. In the case, for example ldap, when a user is added to an LDAP group. is the entirty of the uniquemember list passed to the connector as “create” or “update” attributes or is only the user being updated/added? is that dictated by IDM or my connector?

#13

Yup.

You’re welcome! I’m glad it’s been helpful.

The simple answer here is that IDM is going to send you everything it knows about for the uniquemember list (based on what is stored in the managed object for your group), and then it falls to your connector to figure out what to do with that data. The more complex (or is it vague?) answer is that you control how IDM interacts with your connector through the provisioner and more importantly the sync configuration, and you can really tailor IDM to suit the needs of your connector and your target system.

1 Like
#14

thanks. I’ve got a schema object in place now. going to do some tests today and see how it goes. Thanks much again. I’m sure I’ll have follow ups. :)

2 Likes
#15

This is an old post, but it might be worth to add some clarification.

  1. You could write a connector without providing a schema (e.g the Schema operation can just return an empty Schema object). This schema is used as a template by the UI to generate the object types in the provisioner file configuration - using the /system endpoint action createFullConfig. This is discussed in https://community.forgerock.com/t/developing-a-groovy-connector

  2. The schema that is displayed in the Object Types tab in the connector’s admin UI is derived from the provisioner configuration.

Regards
Patrick

2 Likes