Les Hazlewood wrote:
>> 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!
cool, I'll point you at a few others I know of (spring security also has
an impl btw), but a new impl might be a good idea..
> 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)
ah, cool! I like that.
>> 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?
yes and no. but mostly no ;)
With oauth each client(consumer) is sent a random token by the producer
at signup (and it can be periodically exchanged as it expires too).
when the consumer wants to sign something it uses the token. The
producer must keep a map of tokens->appids. The consumers dont ever know
the real userid. This is good from a privacy perspective.
Also, its a common case that the oauth start sequence begins without the
user belonging to any services, hence no id's at all, but its
irrelevant. you need to key on the consumertoken+producertoken (or maybe
just the consumertoken),
>
>> 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.
>
ah, ok then I guess its available in the JMS exporter too. its
definitely not available in the hessian or burlap exporters, and not in
my derivative hessian over xmpp exporter.
>>> 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.
cool. Oauth offers the ability that users can revoke authorities at any
time, so any cache has to offer the ability for apps to clear cache
values. In a federated environment that means you have to check each
time anyway. does Shiro have anything built in to help here?
>
> 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!
sounds good.
Cheers
>
> HTH,
>
> Les
>
