ChrisPope (Customer) asked a question.
We are on G&L 8.0 P08 and are looking to integrate with xMatters for call-out functionality during Terminations (Leavers). I've been told there is a REST API that is available to use from xMatters, and I am wondering if anyone else has done with xMatters or with a similar app .
To do this, I am considering using a REST node in an existing Fulfillment workflow, but it appears this requires a username/password be "hardcoded" in the Authentication section of the node, which isn't optimal. Another option I am considering is using the same Fulfillment workflow to call an external script which would then perform the REST call. This is similar to some other functionality we have, but I don't think there is a way to confirm that xMatters has done the call-out.
Any other solutions/ideas are welcome.
Thanks in advance!
I assume you already collected accounts, groups and roles from xMatters.
Is there a reason you are not considering using AFX REST connector?
Hi @Boris.Lekumovich (RSA), thank you for the reply.
Not all Users have Accounts/Entitlements in xMatters, so most Terms would not involve removing access from the App. Only the app-support folks and a small set of Users have access to the app. So, we'd have to come up with a way to have some "dummy" Accounts/Entitlements for all Users. We've done something similar for another purpose by creating a "dummy" application in G&L and using what we've called "notional" Accounts/Entitlements which don't really exist. This is basically to create some Manual Activities for our Access Management support folks for every Termination. We could replicate this for xMatters but I've always thought this was a little cumbersome.
I was hoping to find something a little more elegant/simple. I was wondering about Change Events and how they work. But I've not found much documentation on how to use them or what their purpose is. However, this might not be the right path to go down though.
I understand the concept of local entitlements and use it when I want to trigger some additional processes via a workflow.
But in your case I'm bit confused.
During termination you want to remove/disable access in xMatters.
Why not collect the access (using REST collector) and during termination remove/disable the associated access (REST connector)?
I think this is the most elegant/simple approach.
Sorry if I wasn't clear...the goal of this interface is not to remove/disable the User access in xMatters. There are only about 20 Users which have access to the App and the provisioning/deprovisioning of this access is already happening through Active Directory connectors and collectors.
The goal here is to trigger a callout for the Termination of any User when they occur...around 2,000+ total employees and contractors, 99% of whom do not have/need xMatters access. xMatters is the enterprise-wide callout solution and it has a REST API that we want G&L to use to trigger the callout during any Termination.
I understand.
Easiest would be to leverage a REST node in a workflow as you can get the response and see if it was a success, if not, you can try again.
What is the concern with hardcoding a password?
The other alternative is using AFX connector (which can support Oauth) and calling a specific capability using a provisioning node in a workflow. However retrieving the status of the REST response is not that straight forward as with REST node.
Thanks @Boris.Lekumovich (RSA). There is a push from corporate to not have credentials be visible/used by individuals and systems in this manner. This of course follows industry trends away from passwords in general due to low security and required manual rotation.
What about the Change Events? Is there a use case for them in this scenario? As I said, I cannot find much documentation on their functionality/use.
I haven't used Change Events feature.
ok. so standard credentials are not allowed to be used.
Is Oauth an approved approach? if yes, then REST connector is the way to go.
Creds are allowed, just frowned upon.
We have used another solution that involves a dummy Directory whose sole purpose is to just to have an AFX connector which does an SSH call to bash scripts in order to run IGL WebServices. I am thinking of doing something similar to call scripts which would do the REST call to xMatters. It just seems like a lot of hoops to jump through just to make a REST call, but it does give a lot more functionality and control, including error handling/logging as well as retry logic, etc.
We're also looking at using Splunk or other monitoring tool to look at log files and trigger the xMatters callout.
AFX connector triggers bash script and the bash script calls G&L webservices... that's indeed seems like an extra hoop. but again, I don't know the full use case.
going back the xMatters. if you apply the same approach with a script, you are not getting rid of the password. you just moving it from G&L to the script.
Same thing with the Splunk approach. the password is not stored in G&L but it's still stored in Splunk. Unless I'm missing something in the proposed solution.
FYI
every G&L webservice can be configured to not require a token if the request is sent from a workflow or a request form.