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 : https://github.com/leleuj/scribe-up-shiro-demo. 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 : http://shiro-developer.582600.n2.nabble.com/Add-OAuth-support-for-Shiro-td7240738.html.