Up to now (1.0.0.M4) the OAuth2 endpoints were implemented as Spring Security Filters. This is a little too restrictive (e.g. it makes it hard to see and control the interaction between the endpoints and the other filters), so we have decided to change it. From tonight's snapshot the <oauth:\provider/> features are split into two groups:
1. Authorization server features - the authorization and token endpoints - are implemented as @Controller beans with @RequestMapping for the endpoint URLs
2. Resource server features - the protected resources - are the same as before: implemented in OAuth2ProtectedResourceFilter.
In addition, the filters that we retained have been pushed into a composite filter which you need to explicitly declare (using <oauth:\provider id="..."/>) and insert into the Spring Security filter chain using standard <custom-filter/> features.
The default endpoint URLs have changed to match the examples in the spec (/oauth/authorize and /oauth/token), and they can be configured in <oauth:\provider/> using attributes with obvious names, replacing the old, less clear *-url attributes. Here is an example configuration (for sparklr2):
Part of the next phase of refactoring will be to pull <oauth:\provider/> apart into <oauth:authorization-server/> and <oauth:resource-server/> to further align with best practice and the terminology used in the spec.Code:<http access-denied-page="/login.jsp" access-decision-manager-ref="accessDecisionManager" xmlns="http://www.springframework.org/schema/security"> ... <intercept-url pattern="/oauth/token" access="IS_AUTHENTICATED_ANONYMOUSLY" /> <intercept-url pattern="/oauth/**" access="ROLE_USER" /> <intercept-url pattern="/**" access="IS_AUTHENTICATED_ANONYMOUSLY,DENY_OAUTH" /> ... <anonymous /> <custom-filter ref="oauth2ProviderFilter" after="EXCEPTION_TRANSLATION_FILTER" /> </http> <oauth:provider id="oauth2ProviderFilter" client-details-service-ref="clientDetails" token-services-ref="tokenServices"> <oauth:authorization-code/> </oauth:provider>
If you are using <oauth:\provider/>, it would be extremely helpful if you could try out the new version, and make sure that your use case is working. We did make some changes to try and align responses with the spec a bit more, and the namespace XSD has changed a bit.


Reply With Quote