ICF Special Attributes — Why, when, and how?

This topic has 2 replies, 2 voices, and was last updated 3 years, 6 months ago by GuyPaddock.

  • Author
    Posts
  • #19537
     GuyPaddock
    Participant

    I’m coming up the learning curve on OpenICF. Specifically, we’re doing a proof-of-concept implementation of a custom connector based on the OpenICF Groovy connector, with code generated by the Custom Scripted Connector Bundler.

    The biggest challenge right now is that there’s no one place for documentation on the JSON file that the bundler takes in, though a lot of the data in that file is related to similar settings in ICF provisioner JSON files. So, right now I’m having to source from a lot of sample JSON files that ship with OpenIDM to get a sense of what values go where, and what each means.

    More to the point, the concept I’m struggling with right now is special attributes. These are strings like __ACCOUNT__, __GROUP__, __UID__, __NAME__, etc. I have read the Connector Developer’s Guide from back to front, including the section on OpenICF Special Attributes, and yet they still don’t make sense.

    Here’re my questions:

    1. The docs say that these special attributes “enable a connector developer to create a contract regarding how a property can be referenced”. So, does that mean I need to be giving these attributes a value in my connector? If so, how should I be giving them a value? If not, how do I know that?
    2. Where does the value for __UID__ get bound in a connector? Within my connector, how do I indicate that a field in my target system should end up being used as the object’s unique identifier?
    3. How does __ALL__ work? Nothing about this attribute makes sense because it seems to signify “sync everything” but as a property value, I don’t understand where it fits in.
    4. Why are __ACCOUNT__ and __GROUP__ used inside the id and nativeType properties of object types in the JSON? Do I have to use these values in these fields for accounts and groups? What happens if I don’t?
    5. How does this all relate to the ObjectClass type?
    6. What’s up with other special attributes (“operational attributes”?) like __PASSWORD_EXPIRED__? These seem to signify values used differently.

    In general, I would say that there’s no single document that explains this part of the puzzle. The concept gets some brief description in the ICF dev guide, and then the rest of the docs gloss over the details. There are plenty of docs on ICF and IDM that mention “you can use __ACCOUNT__ or __GROUP__ here” but don’t explain what that would actually accomplish.

    • This topic was modified 3 years, 7 months ago by GuyPaddock.
    • This topic was modified 3 years, 7 months ago by GuyPaddock.
    • This topic was modified 3 years, 7 months ago by GuyPaddock.
    • This topic was modified 3 years, 7 months ago by GuyPaddock.
    • This topic was modified 3 years, 7 months ago by GuyPaddock.
    #19844
     gael
    Participant

    That is a lot of questions…

    #1
    some attributes were made “special” because some connectors need them and some were made special because they are quite common when dealing with identities.
    __ACCOUNT__ and __GROUP__ are common object class since they represent users and groups. But your connector may deal with organizations and roles… These 2 are just a generic name for users and groups. You may or may not use them in your connector.

    __UID__ and __NAME__ are special attributes. Those are mandatory. They are part of the “contract”
    => A CREATE MUST always return a __UID__. A Create receives the __NAME__ as part of the attributes of the entry to create.
    => An UPDATE gets a __UID__ as input and MUST return __UID__ as output
    => A DELETE gets a __UID__ as input and return nothing
    => a SEARCH MUST return “Connector objects”. A connector object MUST contain both __UID__ and __NAME__

    __UID__ is the immutable id for an object. It should not change with time. ObjectGUID in AD is an example.
    __NAME__ is a more “human readable” identifier of an object but it may change. Just like a DN in LDAP.

    #2
    it is your connector code that will deal with the __UID__, following the contract. __UID__ does not appear in the provisioner json file.

    #3
    __ALL__ is a special object class used together with livesync when you need the change sequence order from the remote system. Say on LDAP, you create a group, and then you assign a user to that group. Since by default livesync will have different schedulers for users and group, you may end up picking up the user group assignment before the group creation. IF you livesync on __ALL__, then you will get the group creation first and then the user assignment. __ALL__ means any kind of objectclass.

    #4 #5
    nativeType/id is what IDM will pass to the ICF connector as the objectClass. So it is needed here if your connector deals with __ACCOUNT__ and __GROUP__

    #6
    The other special attributes are more like standard attributes that you find in a lot of connectors… __PASSWORD__ for instance. The doc you mention gives a good explanation about that.

    hope that helps…

    #19891
     GuyPaddock
    Participant

    @gael: Thank you — that is very helpful!

Viewing 3 posts - 1 through 3 (of 3 total)

You must be logged in to reply to this topic.

©2021 ForgeRock - we provide an identity and access platform to secure every online relationship for the enterprise market, educational sector and even entire countries. Click to view our privacy policy and terms of use.

Log in with your credentials

Forgot your details?