Layer7 API Management

Hello,

I'm stuck on an approach for migrating portal managed services across my environments.  Let me describe what I have:

• I have several pre-prod environments (let's call them DEV and UAT).
• I have the ability to declare a service as portal managed in DEV.
• Using GMU, I migrateOut my portal managed service from DEV.
• Using GMU, I migrateIn my portal managed service into UAT.
• I can see my newly migrated service in the UAT portal, so I enable it.
• I allow a client to register a new application against the newly published service.
• Problems start here...

When the caller hits the newly migrated service, the API key enforcement breaks.  Although I am passing a valid key, it is not being honored by the gateway. 

My ultimate goal is to define a service in a lower environment and push it along the various environments as they are tested successfully.  I can physically move the service, but something is hung up when I try to involve API keys and plans.  I am not sure what it is though.

Any insight into how to achieve this would be very much appreciated.

Thanks,

Alejandro

8.4 Gateway

3.1 Portal

Hi Alejandro,

Did you ever get to the bottom of this?

The API Key -- Published Service mapping is held in the Gateway's configuration database in a table called generic_entity.  Anytime you add the Portal Managed Service assertion to a Gateway endpoint and save the policy, a new entry is added to this table where the name is equal to the API ID in the assertion.  So, the first thing I would verify is if a new entry actually gets created when a new service containing the Portal Managed Service is created using GMU.  You can use the following SQL before & after to see if the number of portal managed services has changed:

select count(*) from generic_entity where classname="com.l7tech.external.assertions.apiportalintegration.server.PortalManagedService"; 

You can use the following to find the actual entry:

select * from generic_entity where name="5ba10b0e-2f85-4ef3-b6b3-87b7faa73b56"\G

Again, the name value to use in the where clause can be found in the API ID field in the Portal Managed Service assertion of the endpoint in question.  If no such entry exists, then this is likely your problem.

Now, anytime a new application is created in the Portal an API Key is generated on the Gateway and a new entry is added to the generic_entity where the name is equal to the value of the API Key.  You can bring up this entry with the following SQL:

select * from generic_entity where name="l7xxdfc0d02743f9479a92d526c00293288f"\G

In the value_xml field there is a list of service IDs.  This is the list of APIs for which this API key is valid.  The API ID from the Gateway endpoint in question should appear in this list and look something like this:

  <void property="serviceIds">

  <void method="put">

    <string>5ba10b0e-2f85-4ef3-b6b3-87b7faa73b56</string>

    <string>1db2437af8b34992f57aedbb22fe27838f42d019</string>

  </void>

  </void>

If the API ID does not appear in this list this will also cause problems.

This is where I would start my troubleshooting.

Cheers,

Julian

I think this is solved.  I noticed that adding the "Set as Portal Managed Service" does what you describe and generates a new GUID.  The creation of the new GUID was throwing me off.  My policy has a wacky value for one of the context variables that threw the API Key and Plan enforcement assertions off.  Fixing the context variable sorted it out.  It was helpful to understand the relationship between the "Set as Portal Managed" assertion and the GUID generation.

BTW - why is the "Set as Portal Managed Service Properties" dialog editable in Policy Manager?  It feels like these values should be read-only?!

Thanks,

Alejandro