Details

    • Type: New Feature New Feature
    • Status: In Progress
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None

      Description

      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).

      1. shiro-oauth.patch
        23 kB
        Jared Bunting
      2. shiro-oauth-documentation.pdf
        164 kB
        Jérôme Leleu
      3. shiro-oauth-svn.patch
        34 kB
        Jérôme Leleu

        Activity

        Hide
        Jared Bunting added a comment -

        This is a first draft of support for the Resource Server role of OAuth 2.0. It uses amber (which is incubated and not released), so you'll have to build and install that before this will work. I'm mostly looking for commentary on the design and separation of concerns. The authorization server will be coming later - it's a much more complex piece and I'm honestly not sure if it belongs in shiro.

        Show
        Jared Bunting added a comment - This is a first draft of support for the Resource Server role of OAuth 2.0. It uses amber (which is incubated and not released), so you'll have to build and install that before this will work. I'm mostly looking for commentary on the design and separation of concerns. The authorization server will be coming later - it's a much more complex piece and I'm honestly not sure if it belongs in shiro.
        Hide
        Kalle Korhonen added a comment -

        Took an initial look at it. Thanks Jared, good job putting together a complete draft implementation. There's a lot of leeway in implementing an Oauth realm for a resource server and undoubtedly some new interfaces, like OAuthTokenInfoSource is needed. Several iterations are probably needed to make really reusable and generically useful. The IniOauthRealm is more of an example than production code, I might just use it in an integration test rather than package it up into a distributable jar. I'd also like to see end-to-end integration tests for this, but several other pieces are needed. Currently there are not tests at all so there's no way we can just drop it into Shiro source tree as is. Usage of Shiro interfaces is fairly limited, so it doesn't need to be building together with latest Shiro trunk either. I'm thinking that right place for this is therefore http://www.apache-extras.org. That would also make it easier for Jared to directly commit improvements and additions. I can create a project for this there. I'm certainly interested in this topic as a whole but I don't have a direct use case for Oauth resource and authorization server right now (though I'm currently implementing and using other aspects of Oauth) so might be a bit slow from my part, at least initially. What do you think Jared?

        Show
        Kalle Korhonen added a comment - Took an initial look at it. Thanks Jared, good job putting together a complete draft implementation. There's a lot of leeway in implementing an Oauth realm for a resource server and undoubtedly some new interfaces, like OAuthTokenInfoSource is needed. Several iterations are probably needed to make really reusable and generically useful. The IniOauthRealm is more of an example than production code, I might just use it in an integration test rather than package it up into a distributable jar. I'd also like to see end-to-end integration tests for this, but several other pieces are needed. Currently there are not tests at all so there's no way we can just drop it into Shiro source tree as is. Usage of Shiro interfaces is fairly limited, so it doesn't need to be building together with latest Shiro trunk either. I'm thinking that right place for this is therefore http://www.apache-extras.org . That would also make it easier for Jared to directly commit improvements and additions. I can create a project for this there. I'm certainly interested in this topic as a whole but I don't have a direct use case for Oauth resource and authorization server right now (though I'm currently implementing and using other aspects of Oauth) so might be a bit slow from my part, at least initially. What do you think Jared?
        Hide
        Ravi Teja added a comment -

        Has anyone taken a look at [https://github.com/fernandezpablo85/scribe-java|scribe-java]. It's a mature framework for OAuth and supports many OAuth providers out of the box.

        Thanks,
        Ravi

        Show
        Ravi Teja added a comment - Has anyone taken a look at [https://github.com/fernandezpablo85/scribe-java|scribe-java] . It's a mature framework for OAuth and supports many OAuth providers out of the box. Thanks, Ravi
        Hide
        Ciro Vladimir Arreola Camacho added a comment -

        Ravi, I think that is a customer implementation. What's discussed here is the provider implementation. I would really love to see this in Shiro though I haven't used it that much.

        Show
        Ciro Vladimir Arreola Camacho added a comment - Ravi, I think that is a customer implementation. What's discussed here is the provider implementation. I would really love to see this in Shiro though I haven't used it that much.
        Hide
        Henry Saputra added a comment -

        Anyone know what is the revision number of OAuth 2.0 spec being implemented here?

        Show
        Henry Saputra added a comment - Anyone know what is the revision number of OAuth 2.0 spec being implemented here?
        Hide
        Jérôme Leleu added a comment -

        Hi everybody,

        As I'm using the CAS open source project, I submitted a pull request to the CAS community to add OAuth support to the CAS server.

        I reused the OAuth client part of my code to create a shiro-oauth module to add OAuth support in Shiro.

        As someone suggested, it's built on the great Scribe library.

        As I wanted to use my code for both CAS community and Shiro community, I created an open source library : Scribe UP. It's a web-oriented extension to Scribe to get user profile after OAuth authentication process.
        Source code is here : https://github.com/leleuj/scribe-up. It's available under Apache 2 licence. Current version : 1.0.0-SNAPSHOT is available in Sonatype snapshots repository : https://oss.sonatype.org/content/repositories/snapshots.

        My shiro-oauth module is built on my Scribe UP library. This module makes Shiro acts as an OAuth client and therefore authentication process can be delegated to an identity provider like Facebook, GitHub, Google, LinkedIn, Twitter, Yahoo... When using this module, applications can handle security as usual and delegate login process to OAuth providers. After authentication process, the authenticated user has a profile with identifier and attributes.

        I created a demo application to test all the providers and it works great. Just to give you an idea, I copy a configuration sample :
        [main]
        oauthProvider = org.scribe.up.provider.impl.FacebookProvider
        oauthProvider.key = mykey
        oauthProvider.secret = mysecret
        oauthProvider.callbackUrl = http://myserver/myapp/shiro-oauth
        oauthFilter = org.apache.shiro.oauth.OAuthFilter
        oauthFilter.provider = $oauthProvider
        oauthFilter.failureUrl = /error.jsp
        oauthRealm = org.apache.shiro.oauth.OAuthRealm
        oauthRealm.defaultRoles = ROLE_USER
        #oauthRealm.defaultPermissions = defaultPermission
        oauthRealm.provider = $oauthProvider
        roles2 = org.apache.shiro.oauth.filter.OAuthRolesAuthorizationFilter
        roles2.provider = $oauthProvider
        [urls]
        /protected/** = roles2[ROLE_USER]
        /shiro-oauth = oauthFilter
        /** = anon

        I join the SVN patch : shiro-oauth-svn.patch and a complete documention on how the module has to be configured and works technically : shiro-oauth-documentation.pdf.

        Hope you can find my module usefull and integrate it in a further release...

        Thanks,
        Best regards,
        Jérôme

        Show
        Jérôme Leleu added a comment - Hi everybody, As I'm using the CAS open source project, I submitted a pull request to the CAS community to add OAuth support to the CAS server. I reused the OAuth client part of my code to create a shiro-oauth module to add OAuth support in Shiro. As someone suggested, it's built on the great Scribe library. As I wanted to use my code for both CAS community and Shiro community, I created an open source library : Scribe UP. It's a web-oriented extension to Scribe to get user profile after OAuth authentication process. Source code is here : https://github.com/leleuj/scribe-up . It's available under Apache 2 licence. Current version : 1.0.0-SNAPSHOT is available in Sonatype snapshots repository : https://oss.sonatype.org/content/repositories/snapshots . My shiro-oauth module is built on my Scribe UP library. This module makes Shiro acts as an OAuth client and therefore authentication process can be delegated to an identity provider like Facebook, GitHub, Google, LinkedIn, Twitter, Yahoo... When using this module, applications can handle security as usual and delegate login process to OAuth providers. After authentication process, the authenticated user has a profile with identifier and attributes. I created a demo application to test all the providers and it works great. Just to give you an idea, I copy a configuration sample : [main] oauthProvider = org.scribe.up.provider.impl.FacebookProvider oauthProvider.key = mykey oauthProvider.secret = mysecret oauthProvider.callbackUrl = http://myserver/myapp/shiro-oauth oauthFilter = org.apache.shiro.oauth.OAuthFilter oauthFilter.provider = $oauthProvider oauthFilter.failureUrl = /error.jsp oauthRealm = org.apache.shiro.oauth.OAuthRealm oauthRealm.defaultRoles = ROLE_USER #oauthRealm.defaultPermissions = defaultPermission oauthRealm.provider = $oauthProvider roles2 = org.apache.shiro.oauth.filter.OAuthRolesAuthorizationFilter roles2.provider = $oauthProvider [urls] /protected/** = roles2 [ROLE_USER] /shiro-oauth = oauthFilter /** = anon I join the SVN patch : shiro-oauth-svn.patch and a complete documention on how the module has to be configured and works technically : shiro-oauth-documentation.pdf. Hope you can find my module usefull and integrate it in a further release... Thanks, Best regards, Jérôme
        Hide
        Jérôme Leleu added a comment -

        New patch to add OAuth support to Shiro by Jerome Leleu

        Show
        Jérôme Leleu added a comment - New patch to add OAuth support to Shiro by Jerome Leleu
        Hide
        Kalle Korhonen added a comment -

        I applaud the efforts Jérôme. This issue was originally opened for the provider implementation, but that's not to say this issue couldn't necessarily be used for oauth consumer support, just wanted to make it clear for everybody reading this that these are separate issues. Jérôme, do you have the sample application you mentioned available somewhere (github gist or similar, or could just commit as part of scribe-up)? Scribe-centric Oauth consumer support is a good starting point, but what I don't like about this implementation is the required extensions to all of the common Shiro filters, the single Oauth realm and that the provider information is abstracted away and mapped to a role. Also, it's not necessary to use session even for Oauth 1.0a implementation. Nevertheless, this could provide a starting point for an Oauth support. One additional thing I'm still not comfortable with is that how much role Shiro should take when participating in Oauth authentication/authorization call flow. Finally, Oauth is primarily an authorization framework, and I get the need for centralized authentication, but using provided specific protocol is out of scope with Scribe. We probably need to discuss the Oauth support in general on the dev list before moving ahead with it.

        Show
        Kalle Korhonen added a comment - I applaud the efforts Jérôme. This issue was originally opened for the provider implementation, but that's not to say this issue couldn't necessarily be used for oauth consumer support, just wanted to make it clear for everybody reading this that these are separate issues. Jérôme, do you have the sample application you mentioned available somewhere (github gist or similar, or could just commit as part of scribe-up)? Scribe-centric Oauth consumer support is a good starting point, but what I don't like about this implementation is the required extensions to all of the common Shiro filters, the single Oauth realm and that the provider information is abstracted away and mapped to a role. Also, it's not necessary to use session even for Oauth 1.0a implementation. Nevertheless, this could provide a starting point for an Oauth support. One additional thing I'm still not comfortable with is that how much role Shiro should take when participating in Oauth authentication/authorization call flow. Finally, Oauth is primarily an authorization framework, and I get the need for centralized authentication, but using provided specific protocol is out of scope with Scribe. We probably need to discuss the Oauth support in general on the dev list before moving ahead with it.
        Hide
        Jérôme Leleu added a comment -

        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 : 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.

        Thanks,
        Best regards,
        Jérôme

        Show
        Jérôme Leleu added a comment - 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 :  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 . Thanks, Best regards, Jérôme
        Hide
        Jérôme Leleu added a comment -

        new patch with some minor updates

        Show
        Jérôme Leleu added a comment - new patch with some minor updates
        Hide
        Jérôme Leleu added a comment -

        Hi Kalle,

        I didn't get any response from you.

        Did you try my web app demo ?

        What do you think of this LoginResolver concept ?

        Thanks,
        Regards,
        Jérôme

        Show
        Jérôme Leleu added a comment - Hi Kalle, I didn't get any response from you. Did you try my web app demo ? What do you think of this LoginResolver concept ? Thanks, Regards, Jérôme
        Hide
        Jérôme Leleu added a comment -

        New doc and SVN patch for OAuth client support

        Show
        Jérôme Leleu added a comment - New doc and SVN patch for OAuth client support
        Hide
        Jérôme Leleu added a comment -

        Remove final keyword on the OAuthRealm class to allow overriding of authorizations computation

        Show
        Jérôme Leleu added a comment - Remove final keyword on the OAuthRealm class to allow overriding of authorizations computation
        Hide
        Jérôme Leleu added a comment -

        Explain the principals created after OAuth authentication

        Show
        Jérôme Leleu added a comment - Explain the principals created after OAuth authentication
        Hide
        Jérôme Leleu added a comment -

        New patch with minor updates to follow last ScribeUP evolutions

        Show
        Jérôme Leleu added a comment - New patch with minor updates to follow last ScribeUP evolutions
        Hide
        Jérôme Leleu added a comment -

        Follow last ScribeUP improvments

        Show
        Jérôme Leleu added a comment - Follow last ScribeUP improvments
        Hide
        Jason van Zyl added a comment -

        Jérôme, maybe you can just create a separate build in your github account and we can publish to central from there? I just took your patch for now and made a separate build because I'm getting tired of applying your patches over and over. That's what I did anyway:

        https://github.com/jvanzyl/shiro-oauth

        I don't think it needs to be integrated into Shiro proper.

        Show
        Jason van Zyl added a comment - Jérôme, maybe you can just create a separate build in your github account and we can publish to central from there? I just took your patch for now and made a separate build because I'm getting tired of applying your patches over and over. That's what I did anyway: https://github.com/jvanzyl/shiro-oauth I don't think it needs to be integrated into Shiro proper.
        Hide
        Jérôme Leleu added a comment -

        Hi Jason,

        You must be right : last message from Les doesn't give me much hope of making my OAuth client module being integrated into Shiro trunk.
        I do understand your concern about the patches : I'll move the SVN patch into a github project this week-end, with proper build and release processes.
        It will be : https://github.com/leleuj/shiro-oauth-client. Wait a few days and take a look...
        Best regards,
        Jérôme

        Show
        Jérôme Leleu added a comment - Hi Jason, You must be right : last message from Les doesn't give me much hope of making my OAuth client module being integrated into Shiro trunk. I do understand your concern about the patches : I'll move the SVN patch into a github project this week-end, with proper build and release processes. It will be : https://github.com/leleuj/shiro-oauth-client . Wait a few days and take a look... Best regards, Jérôme
        Hide
        Jason van Zyl added a comment -

        I'll talk to Les about getting you access to https://github.com/bujihub

        Les just set it up for contributions to the Shiro project. Things will move faster at Github and I can help setup releases into Maven Central.

        Show
        Jason van Zyl added a comment - I'll talk to Les about getting you access to https://github.com/bujihub Les just set it up for contributions to the Shiro project. Things will move faster at Github and I can help setup releases into Maven Central.
        Hide
        Jason van Zyl added a comment -

        This issue can be closed. We've setup:

        https://github.com/bujiio/buji-oauth

        Show
        Jason van Zyl added a comment - This issue can be closed. We've setup: https://github.com/bujiio/buji-oauth
        Hide
        Jérôme Leleu added a comment -

        It's worth noticing that this JIRA was at first targeting OAuth *server* support in Shiro. The patch I proposed and which has been moved to buji-oauth is only targeting OAuth *client* support so far.

        Show
        Jérôme Leleu added a comment - It's worth noticing that this JIRA was at first targeting OAuth * server * support in Shiro. The patch I proposed and which has been moved to buji-oauth is only targeting OAuth * client * support so far.
        Hide
        Evi Song added a comment -

        Agree with Leleu, we badly need a OAuth 1.0/2.0 server module instead of client module. Currently in Java world there is only an OAuth for Spring Security support server feature, however which depends heavily on Spring & Spring Security.

        Show
        Evi Song added a comment - Agree with Leleu, we badly need a OAuth 1.0/2.0 server module instead of client module. Currently in Java world there is only an OAuth for Spring Security support server feature, however which depends heavily on Spring & Spring Security.
        Hide
        Les Hazlewood added a comment -

        Agreed - I believe we do indeed wish to support both consumer and provider scenarios.

        Show
        Les Hazlewood added a comment - Agreed - I believe we do indeed wish to support both consumer and provider scenarios.
        Hide
        Łukasz Dywicki added a comment -

        FYI there is new OAuth library in Apache called oltu (previously Amber): http://oltu.apache.org

        Show
        Łukasz Dywicki added a comment - FYI there is new OAuth library in Apache called oltu (previously Amber): http://oltu.apache.org

          People

          • Assignee:
            Kalle Korhonen
            Reporter:
            Jason Eacott
          • Votes:
            21 Vote for this issue
            Watchers:
            29 Start watching this issue

            Dates

            • Created:
              Updated:

              Development