Workday Security Group Support (Role, Segment, Implementer)

Identity Security Cloud (ISC) ISC Discussion and Questions
, , ,
1

Hi. Our team has been working on getting Workday Security Groups ingested into IDN such that we can run Certification Campaigns validating Security Groups membership. For this we’d love to leverage the Workday Accounts connector as much as possible, supplementing with scripting using Workday and IDN APIs as necessary.

We have gotten to the point that we have User-based security groups (UBSGs) (and comment data) loaded into IDN, using the connector along with a separate scripting process that ports the comment data from the additional attributes COMMENT field. We are waiting on replies on if there’s a way to skip the port script here and here.

For role-based security groups (RBSGs), we’ve been able to get organization roles ingested into Workday Accounts using an “ORGANIZATION_ROLES” account schema attribute. This does not have support for porting over COMMENT data the way User-based security groups currently do (and the connector team believes it is not currently possible using the Workday APIs per the response here). My own research has not yielded a clear way to pull back role-based security group COMMENT data via API either. My first question is if anyone has worked around this on their own, and what kind of insight they might have about this? My hope is that at the very least some sort of report can be generated in Workday and run/downloaded via Workday API to pull back that COMMENT data, and that we can then use the PATCH entitlement endpoint to update the RBSG entitlements with descriptions.

We also realized recently that our company’s Workday instance makes use of Implementer-based security groups and Segment-based security groups in their privileged access reviews. Once again, it seems like the connector does not support aggregating these groups, nor does it seem that the Workday API can be leveraged to pull back this data. We’re exploring with our internal audit team if we can get by just validating the UBSGs and RBSGs, but there’s a chance we’ll need to be able to manage these in IDN in some fashion still. We’re wondering if anyone else has had to workaround this in their own environments, and if so what kind of guidance they could provide?

I’ve posted similar questions on the Workday Community discussion board as well, here.
Thanks!

2

Hi @imckenzie , I already replied to the Idea link that is mentioned here. Yes, you are right that there is no other way to fetch other mentioned security groups; you will continue to check in near future and if something can be achievable based on feasibility; definitely going to support that. Thanks.

1 Like
3

Hello Ian,

Thank you for posting the challenge you are having integrating Workday with IdentityNow. We are challenged with the same issue. I am hoping by SailPoint Product/Engineering seeing the accumulation of challenges their customers are having the Workday Accounts connector they will prioritize efforts with Workday to expand connector functionality.

I am also hopeful that SailPoint Support / Product will begin responding to customer posts in a timely fashion.

Thanks again

4

Hi @damorales, I am not sure what does you mean in this thread as this thread was already answered on the same date when it was posted. Also, we already have an offline discussion on this thread. If you are having any particular issue or concern on Workday accounts connector, feel free to reach out our support team. Thanks!

5

Hi @imckenzie, just posting this update here as well for everyone’s visibility -

We have introduced a new group schema object for Organization Role (ORG_ROLE##ORG_NAME), that will have following attributes –

  • ORG_ROLE##ORG_NAME - Role_Reference_id##Organization_Refrenece_id
  • Role Name: Name of the role associated with the Organization
  • Associated Security Groups : This will bring the visibility for the role based security Groups associated with the Organization roles.
  • Organization Name: Name of the Organization

From capability point of view –

  • “ORG_ROLE##ORG_NAME” can be managed as a separate entitlement schema object.
  • Associated Role based Security Groups with ORG_ROLE##ORG_NAME will be visible.

As I mentioned earlier, these groups are not directly associated with accounts and it can’t be compared with user based security groups.

For more detail, refer Group Attributes.

For others (in case you are wondering on setting description attribute) - there is no such specific description attribute for User-based security groups. There are occurrences where customer either update it via APIs or by downloading the entitlements and uploading the CSV with the updated descriptions. COMMENT attribute does not indicate that it is a user friendly description which can be mapped with IdentityNow description always. If it is required to be set as IdentityNow entitlement description, you can try this one - Update for this end-point: /sources/{sourceId}/schemas/{schemaId}

Method: PATCH
Headers: Content-Type: application/json-patch+json
Payload:

[
  {    
    "op": "add",
    "path": "/configuration/descriptionAttribute",
     "value": "COMMENT"
   }
]

Thanks!

6

Hi @dinesh_mishra , thanks for the update. This sounds promising, though we had already identified a strategy for UARs using Organization roles.

Do you know if this new group schema object will also be compatible with Account Schema “Organization_Roles” (type: multi-valued Entitlement)? We had focused on using that as opposed to ORG_ROLE##ORG_NAME, as our organization doesn’t make much use different organizations attached to roles in Workday. This is despite “Organization_Roles” only having been recommended to us via email with Workday Accounts team and not via official Workday Accounts docs – exact recommendation having been the following:

If we are not interested in fetching connected Organization to Role which is causing large no of entitlement please use this schema attribute “ORGANIZATION_ROLES” , it will reduce the Number of entitlements being aggregated

7

Hi @imckenzie, no, this enhancement is for ORG_ROLE##ORG_NAME schema attribute and not for ORGANIZATION_ROLES. Even you might have noticed that there is no such OOTB attribute for ORGANIZATION_ROLES. Earlier we used to support it. However, as there were a sub-sequent demand in past for ORG_ROLE##ORG_NAME which is an ideal way for knowing the Role and Organization references, we started supporting this one. Right now, ORGANIZATION_ROLES is working just for backward compatibility but ideally, you should use ORG_ROLE##ORG_NAME.

Even we had a recent enhancement for filtering out inherited Organization roles and fetching only direct assigned roles with accounts, that will also help in the access review process. If there is any further queries or concern, feel free to raise a support ticket. Thanks!

8

Thanks @dinesh_mishra , I opened a support case in case you’d rather respond there. It is case CS0258369

Our issue with ORG_ROLE##ORG_NAME was that it generated roughly 16,000 entitlements for the connector, which then resulted in performance issues if we tried to generate a Certification Campaign – we’d hit a timeout cap due to how resource intensive generating the campaign was. If I check “exclude inherited roles”, I still see the same massive number of these organization role ## org name permutations coming back as entitlements.

9

Hi @dinesh_mishra, I added this comment to the support ticket I opened, but wanted to share here with you as well:

I think I understand the connector docs better now, and realized that the the new functionality Dinesh mentioned is NOT related to being able to aggregate the org roles in form ORG_ROLE##ORG_NAME but then only certifying by ORG_ROLE.

I guess given that, all I’m really hoping for is a) logging above note as an idea for potential support in the future and b) confirmation that the ORGANIZATION_ROLES account schema attribute is not going to have support removed anytime in the near future or without healthy due warning.

Unfortunately, we’re pretty confident that this is more of an issue of a mis-configuration in Workday on our end, in that our Workday administrators assigned many people to roles in every OOB organization. Our team told us this would not be a trivial change to “roll back” into a sensible scoping for our company, which realistically only needs about 3 different organizations max.

Given this concern but still working under a timeline to roll out user access reviews for Workday by EOY, we chose to move forward with Organization_Roles.

10

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.