Stateful Session by Apigee Edge

Not applicable

Is there a problem with session management using Apigee Edge functions (eg javascript policy and Assign Message policy, or Nodejs)?

By doing that, We're worried that the latency will increase and the load of Cassandra will rise.

Session management means keeping the state between Apigee Edge and a client on the Edge.(means "stateful")

We'll use OPDK 4.17.01.

Thank you.

Solved Solved
1 6 2,872
1 ACCEPTED SOLUTION

Hmmmm, good question.

I think the answer depends on how long the state lasts, And how many state objects need to be managed concurrently.

There are several ways to manage state for a user, client app, or "session" in Apigee Edge .

  1. First, there is a Cache. As part of any API request, you can use PopulateCache or LookupCache policies to put and get state associated with "something". That "something" could be a token, or an API key (==client app), or a composite of user + apikey, or something else. Cached data is stored in machine memory. The cache can store data "up to the memory capacity of the virtual machine", which means it's not precisely specified. Each cache element can have an independent time-to-live. If you want to retain information for 30 minutes, you can store it in cache (PopulateCache) with a TTL of 30 minutes, and it will stay for at most 30 minutes. It could be ejected before then, if there is cache contention.
  2. KeyValueMap - The KVM is stored in persistent store. KVM entries do not have a time-to-live. Once stored in KVM, data remains there unless and until it is removed. The backing store for the KVM is a persistent, "disk"-backed store. (They're not disks anymore, but... you know what I mean).
  3. If you use OAuth, then... you can attach custom attributes to any OAuth token that Apigee Edge issues. those custom attributes are stored with the token, and will have a lifetime that is the same as the token. Every time the token is presented in a call, and then is validated by the API Proxy, those custom attributes are slurped into memory, as if in a "session".

If you gave some concrete technical use cases, I could guide you further on which of these might be appropriate.

View solution in original post

6 REPLIES 6

Hmmmm, good question.

I think the answer depends on how long the state lasts, And how many state objects need to be managed concurrently.

There are several ways to manage state for a user, client app, or "session" in Apigee Edge .

  1. First, there is a Cache. As part of any API request, you can use PopulateCache or LookupCache policies to put and get state associated with "something". That "something" could be a token, or an API key (==client app), or a composite of user + apikey, or something else. Cached data is stored in machine memory. The cache can store data "up to the memory capacity of the virtual machine", which means it's not precisely specified. Each cache element can have an independent time-to-live. If you want to retain information for 30 minutes, you can store it in cache (PopulateCache) with a TTL of 30 minutes, and it will stay for at most 30 minutes. It could be ejected before then, if there is cache contention.
  2. KeyValueMap - The KVM is stored in persistent store. KVM entries do not have a time-to-live. Once stored in KVM, data remains there unless and until it is removed. The backing store for the KVM is a persistent, "disk"-backed store. (They're not disks anymore, but... you know what I mean).
  3. If you use OAuth, then... you can attach custom attributes to any OAuth token that Apigee Edge issues. those custom attributes are stored with the token, and will have a lifetime that is the same as the token. Every time the token is presented in a call, and then is validated by the API Proxy, those custom attributes are slurped into memory, as if in a "session".

If you gave some concrete technical use cases, I could guide you further on which of these might be appropriate.

Thanks @Dino.

We're trying to adopt an authentication method that combines OAuth and OpenID Connect into a system for our company.

Please refer to attached image for detailed flow.

4790-flow-oauthimplicit-with-openid-connectimplicit.png

Restrictions are as follows.

· Because it is in-house system, we don't offer authorization consent screen.(both OAuth and OpenID Connect)

· Authentication server doesn't have state.

· Client App is Single Page Application not having web application server.

In this case, while executing OpenID Connect, it is necessary to keep parameters used by OAuth somewhere. Issue the session ID to the client that issued the authorization request (No. [2]) and hold the OAuth parameter on the Apigee Edge. And when I get a redirect of OpenID Connect, I'm planning to restore OAuth parameters based on session ID.

In this case, I think that it is better to use KVM among the proposals by @Dino.

However, by doing this, I'm worried that the load on Cassandra will rise and that normal API calls will be adversely affected.

ahhh, ok. I have done something similar for an implementation of OpenID Connect in Apigee Edge. I used the Cache.

The reason for this: I wanted the session to automatically expire after a configurable period. For example 5 minutes.

This has worked well.

For the cache key, I used the messageid for request [2] in your diagram. This is a context variable that is unique id for each inbound message into Apigee Edge. It's a uuid. I then stored the session information (client id, state, nonce, redirect_uri, and other information) in the cache as a json blob.

Then, the Authentication server can call into Apigee Edge to get additional information for the login-and-consent screen. You said there would be no consent, but ... you still may wish to present to the user some information about what app (client id) they are approving. See the recent Gmail phishing attack for why you want to make this clear. Even for internal apps, I'd want to be clear about what's going on.

Also, I don't quite understand what you mean by "combining OAuth with OpenID Connect". OpenID Connect is simply an authentication mechanism and motion rolled on top of OAuth 2.0. OpenID Connect already includes OAuth 2.0.

But I see from your diagram that you have two token issuers... one is the Authentication Server, and the other is Apigee Edge. So maybe it makes sense to have the more complex flow you've got specified in the diagram.

Thanks a lot @Dino.

I understood using the Cache can realize what I want to do. If possible, can you provide your implementation? I'd like to refer to it.

The Web API itself is stateless, but is it recommend to keep state at Apigee Edge to realize the flow I presented? I understand it can be realized as a function of Apigee Edge. I'm concerned about whether Apigee Edge should have it as its responsibility.

The explanation "combining OAuth with OpenID Connect" might not have been appropriate. It is better to say "use OpenID Connect for authentication part not specified in OAuth". The team responsible for authentication and the team that develops client applications have their own roles and restrictions, and as a result of taking all these into consideration. I don't know if the way it should be.

Yes, here is a community article I wrote last year. It includes a link to the git repo which has all of the code.

Cheers!

Hello @dino
I am trying to use the same logic to store temporarily the user session details instead of the application session.
In other words: having millions of users asking for eligibility in a request then subscribing within another request. I am avoiding the check eligibility a second time when subscribing within 5 minutes...

can a cache be used for this purpose as well?


Thank you ,