PDA

View Full Version : Migration Guide from 1.0.0.M3 to 1.0.0.M5



mboillod
Dec 3rd, 2011, 12:35 PM
Hi,

I'm using spring-security-oauth with Grails plugin: http://grails.org/plugin/spring-security-oauth2-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

Dave Syer
Dec 5th, 2011, 02:34 AM
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.

igorsf
Jan 17th, 2012, 02:51 PM
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?

igorsf
Jan 17th, 2012, 10:22 PM
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


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.XmlBeanDefin itionReader.setEnvironment(Lorg/springframework/core/env/Environment;)V
at org.springframework.web.context.support.XmlWebAppl icationContext.loadBeanDefinitions(XmlWebApplicati onContext.java:87)

igorsf
Jan 18th, 2012, 01:49 AM
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


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.XmlBeanDefin itionReader.setEnvironment(Lorg/springframework/core/env/Environment;)V
at org.springframework.web.context.support.XmlWebAppl icationContext.loadBeanDefinitions(XmlWebApplicati onContext.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.

igorsf
Jan 18th, 2012, 03:03 AM
How can I resolve the following?


2012-01-18 01:00:46,026 ["http-bio-9090"-exec-3] DEBUG org.springframework.web.servlet.mvc.support.Defaul tHandlerExceptionResolver - Resolving excepti
on from handler [public org.springframework.web.servlet.View org.springframework.security.oauth2.provider.endpo int.AuthorizationEndpoint.approveOrDeny
(boolean,org.springframework.security.oauth2.provi der.code.UnconfirmedAuthorizationCodeClientToken,o rg.springframework.web.bind.support.SessionStatus,
java.security.Principal)]: org.springframework.web.bind.MissingServletRequest ParameterException: Required boolean parameter 'user_oauth_approval' is not present

Dave Syer
Jan 18th, 2012, 10:53 AM
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.

igorsf
Jan 18th, 2012, 11:52 AM
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.

igorsf
Jan 18th, 2012, 03:18 PM
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?

Dave Syer
Jan 21st, 2012, 02:03 AM
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?

igorsf
Jan 22nd, 2012, 01:48 AM
Old tokens were given to mobile app users. If we delete them all, users of the app will have to re-authenticate. We only store refresh tokens with the app. Any way of migrating you can suggest?