Hi Jason,
I don't see any Jira issues related to oauth either. Could you please
add one (or more if necessary) to ensure it is not lost?
I'm assuming you're implementing an OauthRealm which acts as an OAuth
Consumer. What is it that you're trying to do exactly? Are you
trying to populate the initial set of roles and permissions based on
interaction with one or more Service Providers during login?
I'm no expert on OAuth, but as I understand it, a token/secret allows
you to interact with a Service Provider on behalf of the User, but
OAuth provides no ability in the protocol to discover what
roles/permissions are granted by the Service Provider. I don't know
how, as listed in your example, you could maintain
(appuserid,token/secret,roles,permissiondata) since you don't know the
last 2 parts of that tuple. Odds are high that I'm interpreting this
incorrectly, so please clarify ;)
As to how to look up a ServiceProvider + token/key pair per user,
consider the following (language agnostic) class:
Token {
String serviceProvider
String value
String key
String type
}
The 'type' attribute would only ever be 'request' or 'access' since
those are the two types defined in the OAuth specification (better
yet, make that an Enum). You could make this a boolean, but my gut
feeling would be to not do that in case the spec ever changes to add
another type.
The 'request' attribute is a boolean because there are only two types
of tokens in OAuth: a request token or an access token. After access
is granted, you can just set that value to false.
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");
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.
This logic would reside in your OauthRealm if you didn't need to
access the tokens any place other than the Realm. 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.
Again, I'm no OAuth expert, but I hope this helped a little. Please
feel free to continue contributing/brainstorming, and maybe we could
get some out-of-the-box support included in Shiro. Also, please don't
forget the Jira issues, otherwise it will definitely get lost!
HTH,
Les
On Wed, Dec 9, 2009 at 10:32 PM, Jason Eacott <[email protected]> wrote:
> hi all,
> I'm new to Shiro, and have discovered this thread relating to oauth:
> http://www.mail-archive.com/[email protected]/msg00088.html
>
> it hints that there are existing Jira issues related to this but I couldn't
> find any.
>
> Has anyone done anything with oauth and Shiro?
> I would be very interested.
>
> if not then perhaps someone might point me the the right direction?
> I'm not quite sure how such a realm in Shiro might best be implemented. The
> problem is that oauth always needs both user and serviceprovider entities,
> and each user has a unique token/secret pair for every service provider.
> Each (token/secret)+serviceprovider association also has its own set of
> permissions.
> So with shiro what would be the best way to carry this forward?
> perhaps a separate store containing
> serviceprovidertoken ->to-> (appuserid,token/secret,roles, permissiondata)
> with which to authenticate the user?, after which I could populate the
> AuthorizationInfo using the appuserid, and permissions discovered here.
>
> Has anyone any thoughts on the best way to use an LDAP directory to store
> such data?
>
> Thanks
> Jason.
>
