Ideas
REST API endpoint for external Azure Access Request call-ins
In this morning's MS Identity Advisors session MS provided a clear indication that they are planning to move towards a call-out model for on-demand Access Request integration with external systems. To get ahead of the curve on this, we could look at offering an extensible REST API endpoint in UNIFYBroker.
Typical usage would be:
Azure sends UNIFYBroker a request for user "bobsmith" asking UNIFYBroker for a certain attribute for that user (e.g. department number) or asking UNIFYBroker to provide an answer to a question (such as "is this user allowed to get access to resource X at the moment?") UNIFYBroker responds and Azure uses that information to approve or deny an in-flight Access Request.
My suggested solution is that the request for user "bobsmith" (and/or "resource X") would map to a adapter record lookup, and the "answer" UNIFYBroker gives back would be the value of one or more fields for that matching record.
Answer
Hi Adrian
Since v5.2, Broker has included the OData gateway, which allows adapter entities to be queried via an OData REST API, which would cover the use case in your example. That said, since it's introduction I don't believe it's seen much, if any, real usage so may not fully support the types of request and filtering features that would be expected of it. Improving the OData gateway is definitely something we're interested in for future releases, so if you have the chance to try it out your feedback would be appreciated.
Also introduced in v5.2, the SCIM gateway provides a REST API conforming to the SCIM 2 specification, a standardized data schema for transmitting identity information via JSON payloads. The primary usage of this gateway thus far has been to connect Broker with Azure AD, which operates as a SCIM client to pull and push standardized users and groups from Broker. I mention it because it does support search and filtering features that would cover your example use case, however the rigid data structure it provides may be too limiting for non-SCIM-specific scenarios.
Thanks Beau, that's excellent. Once MS provide their piece of the puzzle I'll definitely be trying this out.
My 2 cents ... UNIFYBroker has been optimised for sync not querying in the past (not sure about plans for v6) so I am keen to keep REST API call scenarios for Broker treated as an entirely separate set of use cases to the standard feature set. It's important that we don't set UNIFYBroker up to fail by using it in a context for which it has yet to be designed and optimised ... but it is great to be planning for this on the roadmap. Another similar use case is using PowerBI to query UNIFYBroker REST API the same way as a customer is presently using the Litnet REST API to query the MIM service ... if we're going to set the expectation that this is something we want to support (and I think there is much merit in this), I have found through bitter experience that we can't just expect it to work for all cases at scale (and not break other use cases in the process) without building expectation into the product roadmap.
Great points, Bob. In the past the only use cases we've had for the product have been sync based capabilities so that's what the focus has been. However with the addition of the LDAP / ODATA / SCIM gateways, there's been a need for a 'query' based capability which the product has delivered on.
With the future pushing towards cloud based functionality, I'm keen to ensure our roadmap takes these sorts of features into account - so feedback like this is fantastic as it allows us to ensure these items can be built into the roadmap and expectations met appropriately!
Customer support service by UserEcho
Hi Adrian
Since v5.2, Broker has included the OData gateway, which allows adapter entities to be queried via an OData REST API, which would cover the use case in your example. That said, since it's introduction I don't believe it's seen much, if any, real usage so may not fully support the types of request and filtering features that would be expected of it. Improving the OData gateway is definitely something we're interested in for future releases, so if you have the chance to try it out your feedback would be appreciated.
Also introduced in v5.2, the SCIM gateway provides a REST API conforming to the SCIM 2 specification, a standardized data schema for transmitting identity information via JSON payloads. The primary usage of this gateway thus far has been to connect Broker with Azure AD, which operates as a SCIM client to pull and push standardized users and groups from Broker. I mention it because it does support search and filtering features that would cover your example use case, however the rigid data structure it provides may be too limiting for non-SCIM-specific scenarios.