Announcement Announcement Module
Collapse
No announcement yet.
How do I upgrade an existing Spring Security implementation to Spring Security OAuth Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • How do I upgrade an existing Spring Security implementation to Spring Security OAuth

    I have an existing application that utilizes the Spring Security framework and need to upgrade/replace it with the Spring Security OAuth framework. Is there any documentation available that provides guidance on what needs to be done to achieve the upgrade to Spring Security OAuth? I've looked at the Spring Security OAuth User's Guide, but it seems to address what is needed assuming a user is doing a clean installation rather than an update.

    Thanks in advance for any assistance.

    Don

  • #2
    I don't really understand the question. OAuth and the Spring Security core are orthogonal (albeit the OAuth piece has a minimum requirement of SPring Security 3.1). Maybe you should upgrade Spring Security first if you are not on 3.1 yet, and then think about your OAuth needs, which should be an add on.

    Comment


    • #3
      I think he is asking kind of the same questions I was asking earlier. There is a disconnect or misunderstanding on how things work. I mean both are completely orthogonal. They have two different purposes, but both are related in only that they have something to do with security, but they are in different ways.

      Don, what we are saying is that the purpose of OAuth is not for securing your application. Spring Security can secure your application providing user information and Groups/Roles/Permission so uses can register with your application, that data stored in a data store, and then you can have a login with username/password.

      OAuth is for allowing your application to act as a user to some outside third party application, without your application knowing the user's credentials on the third party application. The spec does not cover anything about registration or user account storage because it isn't used (sort of) in the handshake dance of OAuth. Basically OAuth is for not the traditional login but using access tokens for authentication/authorization.

      So you wouldn't use OAuth for users your application to login to your application. There ends up three parties. 1) User of your application, 2) You application, 3) Outside application that your application and it are communicating with each other and that it is secured via OAuth.

      I am definitely paraphrasing the spec, and taking some liberties in my interpretation. But basically the spec for OAuth isn't about logging in to your own application.

      Now, with that in mind, it doesn't mean that in some ways you can bastardize the spec and use it in that way.

      That is what we are trying to do with our applications. Trying to use it as a Single Sign On for our applications. And it is tricky because we are doing something non-traditional and not what it was intended for.

      Thanks

      Mark

      Comment


      • #4
        Mark,

        Thanks for the response.

        I am very familiar with the intent and function of OAuth 2.0 and agree it was NOT developed to be used as a login security system. Although under the "Owner Password Credential Grant" discussion such a usage is mentioned as one possible application for OAuth 2.0.

        My question was more about what steps need to be taken to convert a system currently implementing OAuth 1.x to OAuth 2.0. As you know, OAuth 1.x and OAuth 2.0 are NOT compatible, so I was hoping someone had taken the time to document the steps required to convert a Spring Security based application from Spring Security OAuth to Spring Security OAuth2. I am currently using the Spring Security OAuth2 User Guide to implement OAuth 2.0 and letting the Spring Source IDE point out the errors and then correcting them.

        An example of what I was hoping to find was something like:


        Authorization/Resource Server Changes
        1) Convert "OAuthConsumerDetails" to "OAuth2ClientDetails"

        etc.

        Don

        Comment


        • #5
          Ah. Sorry, it was how you phrased the first post question. It has said from Spring Security to Spring Security OAuth2. But you meant Spring Security OAuth 1.x to Spring Security OAuth 2.

          Personally, I would think you would just write a Spring OAuth2 implementation and use it. Not change the OAuth 1,x implenentation you have. You can replace it completely, or I have heard you can have both implementation running if you wanted to support OAuth 1.x and OAuth2 simultaneously.

          I think there is enough, too much difference to try to "migrate" instead of a fresh implementation.

          Mark

          Comment


          • #6
            Mark,

            Thanks for the response.

            The application supports the Smart Grid Interoperability Panel (SGIP) effort and is being developed as an open-source implementation of the North American Energy Standards Board's Energy Services Provider Interface (ESPI). The security and privacy aspects of the SGIP implementation are governed by the National Institute of Standards and Technology (NIST). The implementation therefore requires that no Personally Identifiable Information be transmitted and that all data transmissions must be done in a highly secure process. Since OAuth 2.0 Authorization Framework RFC6749 deprecated the OAuth 1.x RFC document, we are required to upgrade the current OAuth 1.x implementation to OAuth 2.0.

            Although I realize OAuth 1.x and OAuth 2.0 are not compatible, I was hoping some one else had already done and documented the steps they had to take to remove the Spring Security OAuth implementation and replace it with the Spring Security OAuth 2.0 implementation. I have spent the day creating a very high level Spring Security OAuth 1.0 to Spring Security OAuth 2.0 conversion document as a guide for the developers actually working on the project.

            We'll have to see how it goes from here.

            Don

            Comment


            • #7
              Wow, that is a lot of acronyms.

              Mark

              Comment

              Working...
              X