Announcement Announcement Module
No announcement yet.
Using expressions for <security:http fails in latest oauth2 codebase Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Using expressions for <security:http fails in latest oauth2 codebase

    I've been trying to get the latest source code of oauth2 to work and have paid careful attention to how the sparklr2 sample app works. I am using expressions for my <http: configuration and that doesn't play nicely with the configuration sparklr2 has. If you change the sparklr2 configuration to use expressions and then add hasRole() or hasAnyRole() to the configuration, it fails with:

    2011-10-25 17:10:25.495:WARN:/sparklr:unavailable
    org.springframework.beans.factory.BeanCreationException: Error creating bean with name '': Cannot resolve reference to bean '' while setting bean property 'sourceList' with key [0]; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name '': Cannot resolve reference to bean '' while setting constructor argument with key [9]; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name '': Invocation of init method failed; nested exception is java.lang.IllegalArgumentException: Unsupported configuration attributes: [hasAnyRole('ROLE_USER','DENY_OAUTH'), hasRole('IS_AUTHENTICATED_ANONYMOUSLY'), hasAnyRole('ROLE_CLIENT','SCOPE_TRUST'), hasAnyRole('ROLE_USER','SCOPE_TRUST'), hasRole(ROLE_USER), hasAnyRole('IS_AUTHENTICATED_ANONYMOUSLY','DENY_OAUTH'), hasAnyRole('ROLE_USER','SCOPE_READ'), hasAnyRole('ROLE_USER','SCOPE_READ')]
    That's why it's not working for my web app either.


  • #2
    Did you remember to put use-expressions="true" in the <http/> element? I don't think OAuth2 has anything to say about role-based expressions (but we don't support OAuth2-specific expressions in <http/> yet - there's a JIRA ticket open for it).


    • #3
      Hi Dave.

      Yes I set use-expressions="true".


      • #4
        OK, then what makes you think that this is a problem with S2OAuth? I'm not saying it isn't, I just don't understand why it might be yet.
        Last edited by Dave Syer; Oct 27th, 2011, 05:50 AM. Reason: punctuation


        • #5
          Hi Dave,

          I think the issue here comes down to the voters. The voters fail when turning expressions on. The reason I am saying that is if you remove the access decision manager from the http element, you don't get the error I posted above.
          Last edited by bjornharvold; Oct 27th, 2011, 10:41 AM.


          • #6
            I guess I can understand why the access decision manager as configured in the sample might fail if you switch on expressions. So you need to remove the ScopeVoter, right? It can't be doing anything interesting for you since we don't yet support expressions in <http/>.


            • #7
              Yes, the ScopeVoter seems to be the culprit as far as those exceptions are concerned.

              I've been trying to get the integration tests your wrote to pass and my setup is identical to yours except for the access decision manager reference. Or, at least that's what I can determine so far. When it executes the test testHappyDayWithHeader, it actually fails because "my-trusted-client" gets picked up and authenticated by UserDetailsService loadUserByUsername instead of the clientDetailsService. Trying to figure out why it would do that, so going through configs slowly.

              This fails:
              ResponseEntity<String> response = serverRunning.postForString("/oauth/token", headers, formData);
              assertEquals(HttpStatus.OK, response.getStatusCode());
              assertEquals("no-store", response.getHeaders().getFirst("Cache-Control"));
              Server responds with this after not being to find user by "my-trusted-client":
              [WARN ] LoggerListener.onApplicationEvent():60 - Authentication event AuthenticationFailureBadCredentialsEvent: my-trusted-client; details: [email protected]: RemoteIpAddress:; SessionId: null; exception: Bad credentials
              Even though that url is set up like so:
              <security:intercept-url pattern="/oauth/token" access="permitAll" />


              • #8
                I used isAnonymous() in that URL pattern and it seemed to work fine. Can you post your configuration?


                • #9
                  I 've set it to anonmous and experienceing the same error:

                  Expected :200
                  Actual :401
                  at org.junit.Assert.failNotEquals(
                  at org.junit.Assert.assertEquals(
                  at org.junit.Assert.assertEquals(
                  at com.ccc.test.integration.NativeApplicationProvider IntegrationTest.testHappyDayWithHeader(NativeAppli
                  <security:http auto-config="true" access-denied-page="/403" use-expressions="true" realm="Secure Realm">
                  <security:intercept-url pattern="/administration/**" access="hasRole('RIGHT_LOGIN_ADMIN')" requires-channel="any"/>
                  <security:intercept-url pattern="/user/**" access="hasRole('RIGHT_LOGIN_USER')" requires-channel="any"/>
                  <security:intercept-url pattern="/oauth/token" access="isAnonymous()" />
                  <security:intercept-url pattern="/oauth/**" access="hasAnyRole('RIGHT_LOGIN_USER','RIGHT_LOGIN _ADMIN')" requires-channel="any"/>
                  <security:intercept-url pattern="/static/**" access="permitAll" requires-channel="any"/>

                  <security:form-login login-page="/login" authentication-failure-url="/login?success=false"
                  always-use-default-target="false" default-target-url="/login/redirect"/>
                  <security:logout logout-success-url="/" delete-cookies="JSESSIONID"/>

                  <!-- this will save a cookie on the client side and the system will auto-login a user -->
                  <security:remember-me key="SPRING_SECURITY_REMEMBER_ME_COOKIE" services-ref="persistentTokenBasedRememberMeServices"/>

                  <security:session-management session-authentication-strategy-ref="sas"/>

                  <security:concurrency-control max-sessions="10" error-if-maximum-exceeded="true"
                  expired-url="/login" session-registry-ref="sessionRegistry"/>

                  <security:custom-filter ref="oauth2ProviderFilter" after="EXCEPTION_TRANSLATION_FILTER" />

                  <!-- all non-authenticated users will automatically receive an anonymous user -->


                  • #10
                    I'm not 100% sure why yours is not working, but you have added a few extra pieces I guess. This is fine for me:

                    	<http access-denied-page="/login.jsp" use-expressions="true" xmlns="">
                    		<intercept-url pattern="/photos" access="hasRole('ROLE_USER')" />
                    		<intercept-url pattern="/photos/**" access="hasRole('ROLE_USER')" />
                    		<intercept-url pattern="/trusted/**" access="hasRole('ROLE_CLIENT')" />
                    		<intercept-url pattern="/user/**" access="hasRole('ROLE_USER')" />
                    		<intercept-url pattern="/oauth/token" access="isAnonymous()" />
                    		<intercept-url pattern="/oauth/**" access="hasRole('ROLE_USER')" />
                    		<intercept-url pattern="/request_token_authorized.jsp" access="hasRole('ROLE_USER')" />
                    		<intercept-url pattern="/**" access="isAnonymous()" />
                    		<form-login authentication-failure-url="/login.jsp" default-target-url="/index.jsp" login-page="/login.jsp"
                    			login-processing-url="/" />
                    		<logout logout-success-url="/index.jsp" logout-url="/" />
                    		<anonymous />
                    		<custom-filter ref="oauth2ProviderFilter" after="EXCEPTION_TRANSLATION_FILTER" />


                    • #11
                      I'll start commenting stuff out to see if I can figure out the discrepancy.


                      • #12
                        Figured out what the problem was on this one. Setting <http auto-config="true" registers a basic authentication filter which subsequently fails, when trying to run the NativeApplicationProviderIntegrationTest. The basic filter picks up the my-trusted-client as the user to authenticate with and fails.

                        How can we avoid this? Can we bypass this limitation somehow?


                        • #13
                          It seems like you just need to switch off the auto-config? It isn't very useful in practice, as you have demonstrated. If you actually need the basic auth for some reason maybe we can deal with that as a separate requirement?


                          • #14
                            Hi Dave,

                            That's what I did. Good for now. Thanks for your help.