Using TCP connection as API Session

Not applicable

I am new to Edge. We have an existing HTTP POST based API. The service uses TCP connection as the client session. The client signs on with a POST message and then sends a number of other POST requests (potentially reaching different targets). The TCP disconnect is considered to be the end of the session. The Edge API server uses sign-on message to do authorization and stores it in a thread variable for subsequent calls.

How do I achieve similar flow in Apigee Edge? I read this page: https://docs.apigee.com/api-services/cookbook/using-policy-composition which describes flow to send service requests by composing requests on the fly.

But, I am not yet clear on how to achieve the connection specific context for APIs. ex: what happens if the client issues another API call in the same connection ? Will the auth be reusable?

Solved Solved
0 1 684
1 ACCEPTED SOLUTION

How do I achieve similar flow in Apigee Edge?

You don't.

There is no ability within the Edge HTTP Proxy to manage or monitor the inbound TCP connection. There is no "thread variable" .

Standard REST-ish interfaces are the way to go, and are easy to implement with Apigee Edge.

phase approach
client Sign-on POST /token . Response is a time-bound access token. Authentication of client or user or both is possible. Can also use extensions like PKCE and OpenID Connect.
Key Apigee Edge policy: OAuthV2/GenerateAccessToken
Edge can store additional metadata with the generated token. Persistently, not in a thread variable.
client API auth any verb. any path. OAuth Bearer token transported in HTTP Authorization Header.
Key Apigee Edge policy: OAuthV2/VerifyAccessToken
Metadata associated with the token is brought into context upon verification.

View solution in original post

1 REPLY 1

How do I achieve similar flow in Apigee Edge?

You don't.

There is no ability within the Edge HTTP Proxy to manage or monitor the inbound TCP connection. There is no "thread variable" .

Standard REST-ish interfaces are the way to go, and are easy to implement with Apigee Edge.

phase approach
client Sign-on POST /token . Response is a time-bound access token. Authentication of client or user or both is possible. Can also use extensions like PKCE and OpenID Connect.
Key Apigee Edge policy: OAuthV2/GenerateAccessToken
Edge can store additional metadata with the generated token. Persistently, not in a thread variable.
client API auth any verb. any path. OAuth Bearer token transported in HTTP Authorization Header.
Key Apigee Edge policy: OAuthV2/VerifyAccessToken
Metadata associated with the token is brought into context upon verification.