Page 1 of 2 12 LastLast
Results 1 to 10 of 11

Thread: Migration Guide from 1.0.0.M3 to 1.0.0.M5

  1. #1
    Join Date
    Dec 2011
    Posts
    4

    Default Migration Guide from 1.0.0.M3 to 1.0.0.M5

    Hi,

    I'm using spring-security-oauth with Grails plugin: http://grails.org/plugin/spring-secu...auth2-provider

    This plugin uses version 1.0.0.M3 of spring-security-oauth, and I need to use version 1.0.0.M5 in order to use last improvements and bug fix.

    I've tried to upgrade the Grails Plugin (and make a pull request after that), but there will be an important refactor beetween the two version an I lost myself into classes, filter, endpoint, ...

    Could you help me to maintain the Grails plugin ?

    The list below corresponds to the classes used by the plugin :

    org.springframework.security.oauth2.provider.Acces sGrantAuthenticationProvider
    org.springframework.security.oauth2.provider.InMem oryClientDetailsService
    org.springframework.security.oauth2.provider.OAuth 2AuthorizationFilter
    org.springframework.security.oauth2.provider.OAuth 2AuthorizationSuccessHandler
    org.springframework.security.oauth2.provider.OAuth 2ExceptionHandlerFilter
    org.springframework.security.oauth2.provider.OAuth 2ProtectedResourceFilter
    org.springframework.security.oauth2.provider.clien t.ClientCredentialsAuthenticationProvider
    org.springframework.security.oauth2.provider.passw ord.ClientPasswordAuthenticationProvider
    org.springframework.security.oauth2.provider.refre sh.RefreshAuthenticationProvider
    org.springframework.security.oauth2.provider.token .InMemoryOAuth2ProviderTokenServices
    org.springframework.security.oauth2.provider.verif ication.BasicUserApprovalFilter
    org.springframework.security.oauth2.provider.verif ication.DefaultClientAuthenticationCache
    org.springframework.security.oauth2.provider.verif ication.InMemoryVerificationCodeServices
    org.springframework.security.oauth2.provider.verif ication.VerificationCodeAuthenticationProvider
    org.springframework.security.oauth2.provider.verif ication.VerificationCodeFilter

    Since I''ve upgrade the dependencies from spring-security-oauth [1.0.0.M3] to spring-security-oauth2 [1.0.0.M5] I have noticed the following refactoring

    InMemoryOAuth2ProviderTokenServices => RandomValueTokenServices + InMemoryTokenStore

    DefaultClientAuthenticationCache have been removed...

    And filters has been replaced by endpoint.

    Can you help me ?

    Thanks.

    Manuel

  2. #2
    Join Date
    Jun 2005
    Posts
    4,232

    Default

    I'm not really a Grails user so I'll have to assume you know what to do with the plugin, or that someone else can help you there. If you stick to using the XML namespace then the changes should have minimal impact on an application, but I guess as a plugin author you might need to support some more internal details. Maybe looking at the XSD parsers will help? If you ask some specific questions I can help more easily probably. Also looking at the diffs between the Spring XML config for the sample apps between M3 and M5 is probably a good source of information.

    Everything with "verification" in the name should be "authorization" now. Only the Authorization Server filters have been replaced by endpoints. The refactoring of the TokenServices hopefully is obvious.

  3. #3
    Join Date
    May 2006
    Posts
    20

    Default

    I am attempting to migrate from M3 to M5 (also tried M4) with Spring 3.0.5.RELEASE. In my project all of security configurations are located in applicationContext-security.xml. The problem is with the endpoints. /oauth/authorize is not found.

    In noticed in sparklr all security configuration has moved to spring-servlet.xml. What changed in M4/M5 with endpoints? Do I have to use servlet config instead of application context for spring-oauth2 to create default endpoints?
    Last edited by igorsf; Jan 17th, 2012 at 10:22 PM.

  4. #4
    Join Date
    May 2006
    Posts
    20

    Default

    Why does spring-security-oauth2 1.0.0.M5 depend on spring-beans: 3.0.6.RELEASE instead of 3.1.0.RELEASE? I am getting a conflict after upgrading to 3.1.0.RELEASE with this error

    Code:
    2012-01-17 20:12:41,786 [Thread-2] ERROR org.springframework.web.context.ContextLoader - Context initialization failed
    java.lang.NoSuchMethodError: org.springframework.beans.factory.xml.XmlBeanDefinitionReader.setEnvironment(Lorg/springframework/core/env/Environment;)V
    	at org.springframework.web.context.support.XmlWebApplicationContext.loadBeanDefinitions(XmlWebApplicationContext.java:87)

  5. #5
    Join Date
    May 2006
    Posts
    20

    Default

    Quote Originally Posted by igorsf View Post
    Why does spring-security-oauth2 1.0.0.M5 depend on spring-beans: 3.0.6.RELEASE instead of 3.1.0.RELEASE? I am getting a conflict after upgrading to 3.1.0.RELEASE with this error

    Code:
    2012-01-17 20:12:41,786 [Thread-2] ERROR org.springframework.web.context.ContextLoader - Context initialization failed
    java.lang.NoSuchMethodError: org.springframework.beans.factory.xml.XmlBeanDefinitionReader.setEnvironment(Lorg/springframework/core/env/Environment;)V
    	at org.springframework.web.context.support.XmlWebApplicationContext.loadBeanDefinitions(XmlWebApplicationContext.java:87)
    Fixed. I moved spring-security-oauth2 dependency in the pom.xml to after spring-core dependency and it worked. mvn omitted 3.0.6.RELEASE because of conflict with 3.1.0.RELEASE dependency declare above.

  6. #6
    Join Date
    May 2006
    Posts
    20

    Default

    How can I resolve the following?

    Code:
    2012-01-18 01:00:46,026 ["http-bio-9090"-exec-3] DEBUG org.springframework.web.servlet.mvc.support.DefaultHandlerExceptionResolver - Resolving excepti
    on from handler [public org.springframework.web.servlet.View org.springframework.security.oauth2.provider.endpoint.AuthorizationEndpoint.approveOrDeny
    (boolean,org.springframework.security.oauth2.provider.code.UnconfirmedAuthorizationCodeClientToken,org.springframework.web.bind.support.SessionStatus,
    java.security.Principal)]: org.springframework.web.bind.MissingServletRequestParameterException: Required boolean parameter 'user_oauth_approval' is not present

  7. #7
    Join Date
    Jun 2005
    Posts
    4,232

    Default

    By providing the required parameter? Presumably this is a form submission from your app's user approval page. If the form doesn't contain the right parameters it's not going to work (sparklr2 has a nice template you can copy).

    Note that the latest snapshots depend on Spring 3.1 and Spring Security 3.1.

  8. #8
    Join Date
    May 2006
    Posts
    20

    Default

    Indeed. This was a form submission to login with resource owner password credentials grant type

    curl -i -H "Accept: application/json" \
    -X POST -d 'grant_type=password&client_id=client&username=xyz &password=xyz' \
    http://localhost:9090/webapp/oauth/authorize

    I didn't realize that OAuth2 endpoints with M5 have been redesigned. I am now using /oauth/token and its working.

    curl -i -H "Accept: application/json" -X POST -d 'grant_type=password&client_id=my-trusted-client&username=xyz&password=xyz&scope=read' http://localhost:9090/webapp/oauth/token

    Thanks.
    Last edited by igorsf; Jan 18th, 2012 at 02:11 PM.

  9. #9
    Join Date
    May 2006
    Posts
    20

    Default

    The way token persistence is implemented with JdbcTokenStore is problematic. Refresh Tokens stored and generated with M3 milestone can not be used with M5 because of java serialization errors.. The error seems to be because of upgrade to Spring Security 3.1 Old token was generated with 3.0

    java.lang.IllegalArgumentException: java.io.InvalidClassException: org.springframework.security.core.authority.Grante dAuthorityImpl; local class incom
    patible: stream classdesc serialVersionUID = 1, local class serialVersionUID = 310] with root cause
    java.io.InvalidClassException: org.springframework.security.core.authority.Grante dAuthorityImpl; local class incompatible: stream classdesc serialVers
    ionUID = 1, local class serialVersionUID = 310

    Refresh tokens are typically long-lasting credentials used to request additional access tokens, the refresh token is bound to the client it was issued.

    Is there a way to maintain refresh tokens across different milestones? I could write a migration script that will update authentication blob column in DB with spring-security 3.1 serialized authentication object.. but to do that I have to deserialize authentication column with M3 milestone jar and spring security-3.0 and then serialize it again with M5 and sec 3.1.. not easy. Maybe there is another way?
    Last edited by igorsf; Jan 18th, 2012 at 06:18 PM.

  10. #10
    Join Date
    Jun 2005
    Posts
    4,232

    Default

    If you want to keep the old refresh tokens you will have to work out a way of migrating them - there was no plan to do that in the framework for a milestone release. Can't you just relete them all, and wait for the user to re-authenticate?

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •