Announcement Announcement Module
Collapse
No announcement yet.
client is not redirected to get the token Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • client is not redirected to get the token

    When the client wants to reach a protected resource, the OAuth2RestTemplate makes sure the client will get a token (as we talked earlier): the call to OAuth2RestTemplate.getAccessToken() gets to AccessTokenProviderChain.obtainAccessToken().
    What should happen is that UserRedirectRequiredException will be thrown and this way the client will be redirected to get the token.
    However, I saw that this method gets the authentication from the context, and asks if it is of type AnonymousAuthenticationToken - if so, it throws InsufficientAuthenticationException; and then the redirect will not occur.

    My question - why, in case of AnonymousAuthenticationToken, we have a different exception? In my client (unlike the example) user is not asked for username/password, so I guess that is why I get the AnonymousAuthenticationToken... what should I do then? how can I make sure the client will be redirected?

  • #2
    You can make sure that the <anonymous/> filter is not included in the same chain as the <oauth:client/>.

    Comment


    • #3
      Originally posted by Dave Syer View Post
      You can make sure that the <anonymous/> filter is not included in the same chain as the <oauth:client/>.
      So if I understand you, my client cannot use <anonymous/> authentication?
      and BTW in my client, there is no <anonymous>, yet there IS
      Code:
      		<intercept-url pattern="/oauth/commence" access="ROLE_ANONYMOUS" />
      		<intercept-url pattern="/**" access="IS_AUTHENTICATED_ANONYMOUSLY" />
      so I must change it ?
      Last edited by OhadR; Oct 25th, 2012, 05:51 PM.

      Comment


      • #4
        The anonymous filter is on by default I think, so you have to explicitly disable it. If I were you I'd try and separate the resources that need anonymous access into a completely separate filter chain (<http/>).

        Comment


        • #5
          But what is the idea behind? It is the client we are talking about, not the resource server. Why do I need the client to be protected? Why can't I have my client to allow anonymous users, but only when users try to reach the resource server, only then they will be asked for credentials?

          Comment


          • #6
            This is something of a FAQ. The problem is that the client can't distinguish between two different anonymous users, so it doesn't know that they should have different access tokens with the remote resource. I suppose there might be a way to support anonymous access to remote resources, but only if you are prepared to get a new access token on every request. Raise a JIRA ticket and we can look at how to do it.

            Comment


            • #7
              thanks dave,

              before I raise a ticket, I wanna make sure I understand your suggestion: you said I should make sure <anonymous> is not in my client's chain. I've looked at the tonr, and saw that there IS <anonymous /> in the chain... so why should I remove it? besides, in MY client - I don't have it declared (but you say it is on by default...)

              I saw that in tonr, there is authentication-provider that forces the user to login (to tonr, before sparklr). maybe THIS is my problem? in my case, I want my webapp (the client) to be open, and not force users to login, only when they try to reach the resources (the resource server). does it make sense?

              Comment


              • #8
                Yes, that makes sense. Tonr has it's own authentication manager, and at the end of the day most real applications need one, otherwise you have no way of tracking who your users are. If you had one then it would kick in to provide a non-anonymous authentication where needed. Your best solution is probably to have one that links to the OAuth2 provider itself, so maybe we can work that into the framework. Raise a JIRA ticket and mention that if tonr2 worked without a local user database it would meet your needs.

                Comment


                • #9
                  Done; I've opened this ticket. Hope I did it correctly and clearly.

                  Comment

                  Working...
                  X