Custom hosting of the Trace tool?

Hi Community,

we use Apigee SaaS and would like to create a custom front end for our solution support teams in our corporate design. Apigee metadata like apps and developers are nicely available via the Management API and simple to render in your framework of choice. However the Trace Tool is a different type of animal, rendering a lot of icons in multiple page areas...

Is there any module we can use to embed the trace tool into our custom UI? We can manage to obtain the offline trace data and want to avoid reinventing the whole layout and logic of the existing (well working) trace tool...

Thanks and best regards,
Karsten

2 7 309
7 REPLIES 7

This is an interesting question! I don't have a clear answer for you, at the moment.

But I will do some research.
Today's Trace tool is a single-page-app hosted within the Apigee admin UI.  There may be a possibility to re-host it, though I Can't think of an easy (non-hacky) way to do it right now.  And there may be other possibilities in the future. 

I'll check.

Thank you very much Dino.

 

Btw, if we would have possibilities to hook into the logic of the UI, this might be a workaround for us as well. Our original challenge is that there is no possibility to force hiding the client secrets in apps. Our internal audit team disagrees a large group of support staff has access to the secrets due to fear they can impersonate consumers...

We have initially discussed this with our Apigee Customer Success team and they explained there is no solution for this other than developing a custom UI where we can add our own logic to remove the secrets from the display. So this brought me to my question of how to embed the trace...

Hey @dchiesa1, any update?

Hi Karsten

thanks for your patience.

> Our original challenge is that there is no possibility to force hiding the client secrets in apps.

That makes sense. But I think you're specifically talking about Trace UI.  And there is a way to mask data in today's Trace UI, including things like client secrets. You need to know the names of the variables that will hold things like client_secret, and then you specify the datamask for that

Would that satisfy your needs? 

It will still be possible to subvert this masking, for example if one of your proxies has an AssignMessage that explicitly assigns the value of the masked client_secret variable into another variable, with a name that is not masked. But, if you can avoid that through static analysis of the proxies, then.... the datamasking may work for you.

Let me know if you think this will help you.

Hi Dino,

I am aware of the data masking options and they won't help. The issue is that you can either grant access to the apps section in the UI or you can block it and there seems to be no way to block access to the secrets (or whole credentials) only. Our solution support teams see the need to check developer accounts, apps tied to them and to verify what products, limits and custom attributes are assigned to an app. This requires access to search for apps and to open their details.

Apps returned by the Management API always contain the client ids and secrets assigned to them. Even if we actively remove access to the keys sub-path, still the app response contains the key (but you could not get a response for the key alone). So this is a design issue in my perspective that you define an element (in this case the credentials) as a stand-alone accessible item, but the privileges for this item are ignored when providing the response on the superior item (the app in this case).

 

From the Permissions Reference: https://docs.apigee.com/api-platform/system-administration/permissions

 

We grant "GET" privilege on these paths in a custom role:

/developers/*/apps
/developers/*/apps/*
And we have empty privileges on this path (which should usually revoke access):

/developers/*/apps/*/keys/*
Still when accessing /developers/<example_developer>/apps/<example_app>, the response object contains the key, even though it is not possible to access the key subsequently on /developers/<example_developer>/apps/<example_app>/keys/<example_key>. This is then reflected the same way in the UI and the solution support user can see the client id and secret (together with everything else on the app).

 

To my knowledge there is no feasible way to limit access on what apps a platform user in the UI can see. Since the names are defined by customers upon app creation, it is not feasible to limit the technical names in roles. As a consequence, all users with access to that section in the UI see apps (and keys) of all customers. With dozens of users having this access, our internal audit team highlights a significant risk of leaking keys and potential misuse to impersonate access to APIs on behalf of the customers.

 

Best regards, Karsten

Good stuff, 

Like many things in Apigee, there's an API underneath 

Trace is actually API that returns XML data (not sure about X\SaaS), talking about OPDK. If you are able to retrieve the response from the trace and parse it, you can actually render it with your UI, however, you will need to understand the actual API response format, including all possible policies, errors, etc. 

 

 

upd. : I checked this with my trial Apigee org and there's actually XML\JSON format responses received back to UI. First, when you start the trace, trace opens some session, and then once something arrives at API, UUID of this specific request returned, and then this specific UUID API will get you the data arrived at the proxy. 

 

@dchiesa1 not sure if this is a good idea to allow using this outside the SaaS, there's a reason for 20 requests and 10 mins to be opened for one session.

Right, there's an API to start debugsessions and collect debugsession information. Basically it's the API analogue to the UI button that is labeled "Start Trace Session" (or whatever it's called), and the display of that trace info in the UI. 

The output is... a data blob that conforms to a well-defined schema that describes each traced transaction.  If you take this route, displaying the data in some reasonable form... is left as an exercise for you to implement.