Hey all - is anyone using the delivered Github connector, and specifically, was using the organizationVerifiedDomainEmail attribute? Has it stopped working in the last few months? When I tested this connector months ago it worked, and I was relying on that for correlation, now that I’m ready to move it to production that field no longer pulls in data.
It is also not in the documentation anymore (but is still on the default schema list):
I see from Github documentation that this field seems to only ever be offered via GraphQL. Did this connector used to use GraphQL and no longer does?
I suppose an alternative is to build a Web Services from scratch using GraphQL, which I have started doing; but ran into a lovely non-descript error on aggregation; Exception during aggregation. Reason: {0}
I then said “OK well let me try a CURL query for the group aggregation instead!” but am having issues with that too for some reason (though I am no stranger to Web services connector setups).
Ah I got entitlements aggregating now.
Now all I need to figure out is how the Pagination section works with regards to the endcursor- I haven’t had to deal with that one before.
I suspect once that’s done I’ll be able to handle adding/removing people from teams just fine.
OK well…I got this working on a custom web services connector.
(1) I made some http operations use REST APIs, and and some of them use GraphQL. I used a generic ‘api.github.com’ base URL, and changed the Context URLs to either use /graphql or /<traditionalRESTURL depending on the need.
I do the initial entitlement/account aggregations with REST…but I did a child account aggregation of the main one with the GraphQL endpoint to loop through each person and get their organizationVerifiedEmailDomain attribute AND the teams that they are a part of.
(2) For pagination,
a. The original context url of the query has ?per_page=100 set
b. I set the limit to 100 on the Paging tab
c. I set the body of the tab to:
TERMINATE_IF $responseHeaders.Link.next$ == NULL
$endpoint.fullUrl$ = $responseHeaders.Link.next$
I didn’t realize (though stupidly) that this was sensitive and Github sends back ‘Link’ instead of ‘link’ for response headers.
So while I don’t like that I had to hammer at this as a newb for the last 8 hours or whatever, and the delivered OOTB connector should just work; at least I have a working model.
I was sailing in the same boat when I started using the OOTB GitHub connector. For the organizationVerifiedDomainEmail or public email need to be set visible by the end user itself I believe. A tough spot for correlation as accounts are not really created by SailPoint. We can only sent invite to the users.
I ended up sending communications and documentations to app owners and target users that they need to always use company email to signup to the invite and enforced SAML SSO in the GitHub enterprise. Still the OOTB connector doesn’t support account disable operation, so i would be also moving to Web Services connector as you did.