IBM Security Verify

 View Only
Expand all | Collapse all

Addition of Custom Attributes in User and Person Schema in IBM Security Verify Governance

  • 1.  Addition of Custom Attributes in User and Person Schema in IBM Security Verify Governance

    Posted Thu May 09, 2024 10:00 AM

    Hi Team,

    For one of our customers we want to do a HRFeed integration from their HR application to IBM Security Verify Governance.

    The HR Application is a SaaS application so we do not have access to DB and the integration would be API based.

    We are calling the REST API of the HRMS application from the TDI Assembly Line and then in turn are calling the ISVG Rest API for USER (Add User).

    We need to modify the Person Schema and the User Schema to associate the custom attributes that the HRMS has to ISVG User.

    We tried adding a custom attribute to the Person Schema and then tried to map the same in USER_ERC table but when we call the Add User API then it says that the attribute does not exists.

    The attribute \"salutation\" doesn't exist in the \"urn:ibm:params:scim:schemas:extension:bean:agc:2.0:User\" schema.

    We have around 20 attributes that we need to add to the Person and User in ISVG.

    Please provide guidelines as to how we can achieve this.



    ------------------------------
    Sushant Dusad
    ------------------------------


  • 2.  RE: Addition of Custom Attributes in User and Person Schema in IBM Security Verify Governance

    IBM Champion
    Posted Fri May 10, 2024 03:16 AM

    Hey Sushant,

    Updating the USER_ERC schema is definitely something you can do if you need additional attributes to support your use cases.

    Updating the PERSON schema, however, is not something you should do and nor should you have to do it. I can't think of a use case that would require you to do that.

    Provisioning actions to downstream systems can map attributes from the USER_ERC table directly to the account object - take a look at Account Configuration > Target Attributes.

    Any rules that you write can also lookup the information in the USER_ERC table at runtime. The classes/methods support getting access to the information, or you could use simple SQL queries to get the data you need.

    Finally, user creation/modification forms act on the USER_ERC table itself so the data that is in there will be available to you to support those use cases.

    In short, don't update the PERSON table. You shouldn't need to.

    NOTE: If you believe you do need to, I'd love to hear your use case.



    ------------------------------
    Stephen Swann
    www.madigansolutions.com
    ------------------------------