We are currently exploring options to onboard Workday Security Groups into SailPoint IdentityNow and would like some guidance.
We wanted to understand if it’s possible to achieve this using the out-of-the-box Web Services connector in IdentityNow — specifically to aggregate and manage Workday Security Groups — or if this would require development of a custom connector instead.
Has anyone implemented a similar use case where Workday Security Groups were onboarded? If yes, would appreciate any inputs on:
Whether it was done using the Web Services connector
What type of API calls (Workday REST or SOAP) were used
Any limitations or challenges faced
Suggestions or best practices for this integration
Thanks in advance for your insights!
Best regards,
Isha Singh
What have you tried?
What errors did you face (share screenshots)?
Share the details of your efforts (code / search query, workflow json etc.)?
What is the result you are getting and what were you expecting?
As aggregation of Security Groups is listed as a supported feature of the Accounts connector ( Supported Features ) it might be best to share your issue with getting it to work.
Actually there are two types of security groups “User_Based_Security_Group” and “Security_Groups” we are able to handle “User_Based_Security_Group” but “Security_Groups” are not getting provisioned. Which is why we were thinking to go via webservices connector approach or any other custom connector.
Hi @IshaSingh As far as I know, to get the non-user based security group types you need to have a calculated field created in WD. The SP documentation isn’t great, though, see Troubleshooting
For aggregation it’s working. All the security groups were aggregated but when we are trying provision user to the security groups, it is failing which is why we are thinking to go via webservices connector or custom connector.
Hi @IshaSingh I don’t believe there is a way to add accounts to non-user based security groups because they’re not directly associated with accounts. Accounts acquire them through rules, hence why a calculated field is required to aggregate them. There’s about 20 different types of rules that are used. You could potentially see which rules are attribute based and then provision those attributes, but those attributes are probably based on business processes so you would be defeating the purpose.
Thankyou for your response. We are able to successfully provision user based security groups. We are facing problem with security groups. Did you created one to one roles of security groups and provisioned users to them?
We need security Groups linked to source workday saas application so that we can provision users to those groups. Could you suggest me whether webservices connector is correct route to go with or we have to with custom connector.
Hi @IshaSingh As I said above, I don’t think there is a mechanism to add Workday accounts to (non user-based) Security Groups as they are not directly associated with accounts. Think of them as “Dynamic” groups. You could assign the attributes or WD Roles that are used in the rules associated with the Security Groups, but you would need to check the rules and as I also said before, that would defeat the purpose of the dynamic-ness of the Securyt Groups.
Hi @IshaSingh Did this help with your understanding of why you can’t add WD accounts to non-user based Security Groups? It would be helpful for future users of the forum if you could let us know how you are getting on.
