> demo provider, but it works. internally its a bit odd, but still simpler
> than the reference impl. and there has been some effort to make the
> datastore extensible, but its consumer impl is still too tied to http for my
> immediate needs.
> ref: http://code.google.com/p/dyuproject/
Cool - that project is Apache 2.0 licensed. If the community felt it
prudent, we could investigate using that as a backing implementation
for a complete Shiro OAuth support module. Without looking at the
code, I'm not sure if we'd want to do that though or if it would make
more sense to have our own implementation for a more integrated
solution. Ideas are welcome!
>> Now, you _could_ have one or more Token instances each be a single
>> principal in the PrincipalCollection returned by your OauthRealm.
>> Then you could access these tokens anywhere in your application by
>> calling subject.getPrincipals().fromRealm("oauth");
>
> not sure I like this, as users/principals have other properties so wouldnt
> this approach lead to 1 user effectively becoming many?
In Shiro, a principal is not a user. It is an identifying attribute
of a user, like a username, a given name, a surname, a social security
number, etc.
A Shiro Subject is just a security-specific 'view' of a single
application user. The subject can have many principals, and
internally Shiro remembers from which realms all of the principals
came from. This makes it easy for Realm implementors to acquire only
the principals their realm 'cares about' and ignore other principals
that perhaps came from other Realm implementations that may be in use
as well (e.g. multi-realm PAM scenarios)
>> Note however that PrincipalCollections should be as lightweight as
>> possible since principals are often stored in the Session and
>> serialized as cookies in web apps. But this might be ok/negligible
>> for your app though - YMMV.
>
>> A better performing approach would be to do as you suggested - store
>> the Tokens in a separate store. I would probably key the lookups
>> based on your application unique user ID for very fast lookup. You
>> could also store the Token in a map, keyed by serviceProvider:
>> Map<String,Token> tokens = getServiceProviderTokens(applicationUserId);
>> Token token = tokens.get(serviceProvider);
>> //call the Service Provider with the info in the returned Token.
>
> I like your thinking but unfortunately I dont think this can work since the
> lookup has to occur on the oauthtoken/key first in order to discover the
> userid.
I'm confused - don't you know the user id _before_ the OAuth exchange
sequence is initiated?
> I already have code to do the oauthy bits, and I'm using a spring remoting
> service exporter (over xmpp) for my serviceprovider->server transport. I
> initially thought I could use the shiro SecureRemoteInvocationExecutor but
> that ONLY works with the http exporter
At least in current SVN, this is not the case. There is nothing in
the SecureRemoteInvocationExecutor that references any HTTP API. I'm
actually currently using it in an application for remoting over JMS
which is not HTTP-based.
>> Otherwise, you'd
>> probably have to put that logic in a Service/Manager of some sort for
>> access by the application elsewhere. Then the OauthRealm could use
>> this service/manager if it needed the same data at some time later.
>> This approach is naturally more complex than just storing the Tokens
>> as Subject principals, but it would probably be a better performing
>> alternative. YMMV depending on your app.
>
> its difficult to come up with a performant solution here since for any
> single user there may be many tokens and permission sets, so if the app has
> a large number of users, just maintaining this list becomes a challenge. One
> alternate solution which is employed by the likes of yahoo is not to store
> this data at all, but to carry it all encrypted in the oauth signature.
Sure, you could do this, and that would be fine. But the many
tokens/permission sets would work fine in Shiro as well - during a
login, you just return this information in the form of an
AuthorizationInfo object. If you have caching enabled in Shiro, you
increase performance even more by reducing round trips to the
datasource.
But ultimately a Realm is basically a security-specific DAO, so you
must have some sort of datasource that it can communicate with to
formulate data into roles/permissions that Shiro can understand.
Datasource instances and data models are outside of Shiro's control,
so those have to be defined by the application developer. That being
said, if you come up with some good ideas in this area that you think
are applicable to most OAuth applications, please share!
HTH,
Les
