In Apigee, how can developer accounts for an organization be accessed through a policy?

Question

In this use case, in an API Proxy, a custom attribute for each developer in an organization has to be accessed.

I am aware of the call ' https://api.enterprise.apigee.com/v1/o/org_name/developers ' which will give a list of emails (usernames) of all developers and then I can use ' https://api.enterprise.apigee.com/v1/o/org_name/developers/dev1_email@abc.com ' to get a particular developer account.

I tried using the Service Callout policy to get a list of all developers, returning developer emails:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ServiceCallout async="false" continueOnError="false" enabled="true" name="get-developer-list">
    <DisplayName>Get Developer List</DisplayName>
    <Request learPayload="true" variable="DeveloperListRequest"/>
    <Response>DeveloperList</Response>
    <HTTPTargetConnection>
        <URL>https://api.enterprise.apigee.com/v1/o/myOrg/developers</URL>
    </HTTPTargetConnection>
</ServiceCallout>

However, this requires a username and password which can be set by an Assign Message policy. How can this be achieved? Is this the right approach overall or is there any other way?

Answer 1

You should avoid calling out to the management server in most cases. The management server endpoint is not built for the same amount of traffic that you can handle in your APIs, and you can cause it to stop responding if you overload it.

To access a developer's information, you can use the AccessEntity policy:

<AccessEntity name="GetDeveloperInfo">
    <EntityType value="developer"/>
    <EntityIdentifier ref="variableHoldingIdentifier" type="developeremail"/>
</AccessEntity>

You specify the variable that holds the id of the developer you want to access in the EntityIdentifier ref attribute. The EntityIdentifier type attribute holds the type of data you are using to access the entity. For developers, you can access via email, developer ID, appID, or consumerKey. See the AccessEntity docs for more details.

If you need to start with a list of all developers, you can't do that via a standard policy, and you'd have to call out to the management API for the list, but you should still use the AccessEntity policy to retrieve the developer's data.

If you worry at all about security, I would recommend that you create a user specifically to do your callout with a complex password. Create a custom role that only allows GET access to read the developer list, and assign that user that role only. Putting the password in the API directly means that if you download the bundle/archive the source code somewhere, the username/password can be compromised. You could store an encrypted version of the password in a key/value map, and retrieve it from there and decrypt it in the API, so that someone would have to get both your bundle and access to your key/value map data to get any access. In any case, if you've properly locked down the access for that user, someone who gained access to the user credentials could only get the developer list, and nothing else.

To avoid calling out too often (and swamping your management API endpoint), you could cache the response from the management API for a certain period (a minute or more). That would avoid the problem of heavy traffic hitting the management API.