StorageService: how to read/store a collection of records

[Cantor, Scott]

On 12/22/15, 11:14 AM, "dev on behalf of Misagh Moayyed" <dev-bounces at shibboleth.net on behalf of mmoayyed at unicon.net> wrote:



>Reviewing the StorageService interface, I am trying to find a way to read a collection of records. Here is the use case:
> 
>For OIDC, I intend to delegate the management and storage of Oauth tokens (refresh/access) to the storage service. For this to work, I need to find a way to retrieve a collection of tokens that are persisted by the service and do additional processing on them. Of the current impls, I only see the JPA variant doing something like this, specific to that implementation. The contract seems to not specify a way to do this as far as I can tell.

Sometimes there's a higher level key that can be used, in which case you store them all in a common context, but even in that case you can't iterate over the context, so you normally have to maintain a secondary index record containing a list of the keys.

> 
>My other option would be to skip the storage service API completely, and rely on a JPA backend of my own, handle schema changes and so on independent of the idp itself. This is something that mitreid connect does by default, and I am wondering if I should go that route if it makes things easier in the long run both for dev and management purposes of the token.

Bad idea in almost every case, but how bad depends on the use case. If there's no plausible back-end that makes sense other than a database, then it's occasionally not the worst idea. I still wouldn't use JPA, just use JDBC. SQL is not meant for storing objects and no library will ever make that a good idea. SQL alone is much better than any abstraction of it.

I guess it depends how durable the tokens would have to be, but even for that kind of case, I expect there will eventually be some other attractive storage options we'd lose out on by avoiding the API. The goal of the API isn't to make your life simple, but to make the IdP's storage job simple. The complexity is pushed into the storage API client and out of the storage plugins.

-- Scott