6 Replies Latest reply on Mar 4, 2013 3:14 PM by john.sprinkle@db.com

    Customizing Jive's OAuth Implementation

    john.sprinkle@db.com

      Hi,

       

      We're working on making Jive Anywhere compliant within our organization, and we've come across a an important edge case.  Essentially, we'll be setting the life of OAuth access tokens to about 1 hour, which there is a system property that can accomplish.  Leaving the life of the OAuth refresh token at the default of two years, my understanding is that new access tokens should be obtained effortlessly (and the user will be none the wiser).  The sticking point here is that every time an attempt to retrieve a new OAuth access token is made, we need to check with other systems to see if they still have the rights to access our instance of Jive. 

       

      I'm looking at overriding parts of the JiveOAuth2AuthorizationFilter and JiveOAuthTokenManagerImpl classes to accomplish this, but I'm not entirely sure I'm on the right track yet.  Has anyone else tried something similar, or does anyone have insights that might help?

       

      Thanks,

      John

        • Re: Customizing Jive's OAuth Implementation

          John Sprinkle,

          This is an awesome question. I'm going to @mention the Jive Anywhere group as well. They might be able to give you specific pointers on how to solve this.

          • Re: Customizing Jive's OAuth Implementation

            Amir Leshem, can you help out here please?

                • Re: Customizing Jive's OAuth Implementation

                  John Sprinkle,

                   

                  It sounds like what you need is to add a security filter to the oAuth2AuthorizeChain chain that will check each authorization request for validity with you auth provider. This will allow you to integrate just in the point the access token is generated, and fail the process if your auth provider says no-go.

                   

                  The mentioned chain applies to /api/oauth2/authorize/** and /api/oauth2/activate/** which are the points where you renew and establish oauth relationships respectively.

                    • Re: Customizing Jive's OAuth Implementation
                      john.sprinkle@db.com

                      Hi Re'em Bensimhon,

                       

                      That was my thought behind customizing the JiveOAuth2AuthorizationFilter, which seems to already be on the oAuth2AuthorizeChain.  I can successfully watch requests to get an initial set of OAuth tokens come in to that class by issuing log messages in the "attemptAuthentication" method.  What I have been unable to do, thus far, is find the bit of code that handles issuing new access tokens when old ones expire, and I've been digging around in Jive's OAuth implementation a lot lately (it's possible I'm just missing something here).  I've lowered the ttl on the access tokens using the "jive.oauth.acess_token.ttl_hours" system property to speed up the expiration process in an effort to find what I'm looking for.  However, the renewal process for access tokens does not appear to have anything to do with the "attemptAuthentication" method.  I'm assuming that since requests from Jive Anywhere have the user's OAuth string attached to them, there must be some central point in the code where each request has the token extracted, and the token's expiration date is analyzed.  Can you confirm this is the case?

                      • Re: Customizing Jive's OAuth Implementation
                        john.sprinkle@db.com

                        Alternatively, it's possible I could use our existing filter (which every request to the server passes through) and apply logic there if the request was to any of the core or oauth apis and has an attached oauth authorization header.  Presumably, I could use the access token string from the request header to collect the associated user id and access token expiration date from the database.  If the token is expired, I could then check with other systems in the organization to see if the user is still allowed write access to platform.  If the user shouldn't have write access anymore, I could disable him/her on the spot.  However, I've been unsuccessful in locating existing logic to extract OAuth token information from the database based on an access token string.  I could roll my own dao, but I'd prefer not to if one exists- any idea if this is the case?