Layer7 API Management

Hi,

We have a requirement to create generic policy for multiple entities, need to validate entity type which is coming from URL and route the request to required entity.

I have created policy with 2 routing assertions for 2 entities with validation on entity type and hard coded user and password in routing as credentials are different for both the entities.

We would like to know if it is possible to pass credentials dynamically to single routing assertion based on the entity type, if it is possible then could you please suggest how to maintain the credentials and pass the same in routing identifying the entity type. 

Regards,

Rathnakar

Hi Rathnakar,

Are you trying to pass through the authentication from the Gateway service to a route assertion? or just dynamically set the credentials based on the entity type?

Depending on your needs, we have the ability to store passwords in the gateway and reference via context variables. These can then be used in the route assertion.

Stored Password Properties - CA API Gateway - 9.2 - CA Technologies Documentation 

If you are protecting the endpoint with basic auth you can  extract the credentials from the authorization header and pass this to the route assertion via context variables.

Regards,

Joe

Hi Joe,

Thanks for the quick response.

we are not passing credentials through the authentication from gateway service, need to set the credentials dynamically based on entity type.

I have to validate entity type in policy and based on the entity type, need to pass corresponding credentials in routing. do we have key/value map in Layer, if yes please suggest how to maintain the values and reference via context variables.

Regards,

Rathnakar

Hi,

We have created policy to select the entity credentials dynamically from cluster variable and manage stored passwords based on entity type

maintained cluster wide properties for all entities as entity1^user1|entity2^user2...

^ as separator between entity and username and | separator between multiple entities

also storing passwords for all users in managed stored passwords with key name username. user1, user2 as manage stored password name in this case

Splitting cluster wide properties 2 times based on pattern | and ^, capturing entity name and validating with entity from request URL, if it is matching then considering 2nd value in array as username and trying to retrieve password(${secpass.${username}. plaintext}) for that user from managed store passwords and passing user, password context variables in routing.

${secpass.${username}. plaintext} for retrieving password for username is not working, password not storing in context variable.

If a new entity introduced, then we don’t want to change the policy, instead adding entity details in cluster wide properties and manage store passwords as mentioned above and trying to retrieve credentials based on entity type in request URL. we would like to know if it is possible use case, so please suggest how to retrieve password dynamically.

Regards,

Rathnakar

just to attach policy created for above requirement.

I've attached a sample policy that will take

1. a service published with the second part of the URI as the trigger for the entity
2. lookup against the cluster wide property gateway.entityUser for the user
3. Determine the password from the Manager stored passwords
4. Pass the user and password through to the HTTP Routing assertion

Example URI: /user/foo1

Example gateway.entityUser CWP: foo1^user1|foo2^user2|foo3^user3|foo4^user2

Example for the passwords: user1 with password pass1, user2 with password pass2, etc

Please note that you will need to ensure that you add in error handling for if a user/password combination is not found.

Sincerely,

Stephen Hughes

Director, CA Support

We did something similar for one of our use cases, but we did not want the identity name passed in the URI to be the same as the actual user that should be used, for security reasons. We also took into consideration the fact that there could be multiple times the same username for different routes, but with different passwords (i.e. apiuser). So we did the following:

1. Parse the identifier from the URI as you did

2. Use a Map Value assertion to map that identifier to a semi-colon-delimited value consisting of:

      a) A prefix string

      b) The actual username to use in the route

      c) The URL to route to for that identifier

3. Split the result of the mapped value into its 3 parts (${prefix}, ${username}, ${route_url}

4. Lookup the password in the stored password using the ${prefix}_${username} syntax.

5. Route to the ${route_url} using ${username} and password resolved in step 4.

Of course, for added security, we catch each step that could fail and return the appropriate HTTP response accordingly then Raise Error. (i.e. 401 for password not found in store, or missing map in Map Value, 404 for invalid identifier in URI, etc...)

That allows for a completely dynamic routing with dynamic basic auth.