We have a requirement to create a form to allow user to provide input to attribute values. Once user submits the form and entry will be created in a delimited source. This delimited source is a trusted source. Now we need to generate a networkID attribute value based on the value provided by user through form and this network ID should be Identity account Name and also need to be used for SSO login.
Once this ID will be generated we need to validate it for uniqueness check. which build Map does not support and delimited source support this rule.
Issues:
As delimited source was a trusted source therefore we made some random no as account ID and account name and we know that Identity account name cannot be modified later.
Please suggest an approach so that this networkID attribute can be made Identity account name.
As we cann’t call rule in a workflow neither we can use create profile to create account as account is directly getting created through API within workflow using form input. Therefore using account attribute rule also ruled out.
I read few documents and I think we cann’t use before provisioning rule for delimited source.
Please suggest possible approach to achieve this usecase.
@BhawnaAgrawal
For this use case, do not create the trusted source account with a random Account ID / Account Name first, because once the account is aggregated and linked, the native identity / account name should be treated as immutable in ISC.
Recommended approach:
Generate the networkID before creating the account record in the delimited trusted source.
Use the Workflow/Form submission to call an external service, Azure Function, Lambda, or API layer.
That service should:
Receive form input
Generate the networkID
Perform uniqueness validation against ISC identities/accounts or the target system
Return the final unique networkID
Then create the delimited source account using this networkID as:
Account ID / Native Identity
Account Name
Identity attribute used for SSO login
Build Map is not the right place for uniqueness validation, and Before Provisioning Rule is also not suitable here because it is meant to modify provisioning plans, not generate new account attributes. SailPoint also recommends using account creation configuration/provisioning policy for account creation values instead of Before Provisioning Rule for creating new attributes