shiro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jérôme Leleu (Commented) (JIRA) <>
Subject [jira] [Commented] (SHIRO-119) Oauth support
Date Sat, 18 Feb 2012 08:56:59 GMT


Jérôme Leleu commented on SHIRO-119:

Hi Kalle,

Thanks for spending time on my patch and documentation.

You're right, my module is for OAuth consumer support. As Les told me to contribute to this
JIRA, I add doc and patch to it. But I can create a new JIRA dedicated to OAuth client support
if you want.

I add my sample demo application on my github :
Let's play with it.

I agree with you : extending all the Shiro filters is ugly. I'm not pretty happy with this
solution, but at least it's easy to understand and not too invasive for Shiro core.
My first idea was to change the AccessControlFilter and add to it a LoginResolver (with getLoginUrl()
and setLoginUrl() methods) with a DefaultLoginResolver with sets and gets a simple url. This
way, I would have created an OAuthLoginResolver with a "does nothing" setLoginUrl() method
and a getLoginUrl method which returns the authorization url of the provider. Maybe I could
have define this LoginResolver at the SecurityManager level.
What do you think of this LoginResolver ? Do you have a better idea to handle this problem

I don't understand why you don't like the single OAuth realm. What is the problem with that

About provider information, I understand your point of view but I think it's not a real use
case. OAuth providers are Facebook, Twitter, Google... and they don't have any information
about roles or permissions, they just have personal information about the authenticated user.
That's why I choose to grant default roles or permissions without taking into account attributes
given by the provider. For the CAS integration (SHIRO-285), I used attributes returned by
the CAS server to grant roles and permissions, but I think CAS servers generally belong to
your own organization and roles/permissions can be brought by attributes in that case. However,
taking into account attributes from OAuth provider for roles and permissions wouldn't be too
hard to do.

Regarding OAuth protocol version 1.0, I'm not an expert but I don't see how you cannot use
the session. The request token retrieved before the user is redirected to the login page of
the OAuth provider has to be stored, to be reused when user come back to the callback url
to finish the OAuth authentication process. It cannot be recreated. To be more precise, the
request token has a token and a secret, the token is retrieved on the callback url but not
the secret. However, the secret is used for the signature of the access token request. I didn't
make it work without session. If you have any solution, I would be very happy to hear it.

I don't understand last part of your comment starting at « I'm still not comfortable with
is that how much role Shiro should take when participating ».

We can continue this dicussion on the thread I opened about OAuth support :

Best regards,

> Oauth support
> -------------
>                 Key: SHIRO-119
>                 URL:
>             Project: Shiro
>          Issue Type: New Feature
>            Reporter: Jason Eacott
>            Assignee: Kalle Korhonen
>         Attachments: shiro-oauth-documentation.pdf, shiro-oauth-svn.patch, shiro-oauth.patch
> Create support for OAuth provider  support 'out of the box'. 
> This could involve a standalone provider webapp with some flexible mechanism for data
storage, and/or remote data retrieval & management,
> and a customisable way to integrate application/transport specific OAuth based authentication
with Shiro (HTTP/XMPP etc).

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


View raw message