Spring Security OAuth
  1. Spring Security OAuth
  2. SECOAUTH-129

Remember authorization decisions for individual client/user combinations

    Details

    • Type: New Feature New Feature
    • Status: Resolved
    • Priority: Minor Minor
    • Resolution: Complete
    • Affects Version/s: 1.0.0.M4
    • Fix Version/s: 1.0.0.M6
    • Component/s: OAuth 2
    • Labels:
      None

      Description

      This will not require the user to authorize each and every time he access the resource from the service provider except the first time.

        Activity

        Hide
        Dave Syer added a comment -

        I'm working on a solution using the UserApprovalHandler. I think it looks like the right direction and will address both this issue and SECOAUTH-205.

        Show
        Dave Syer added a comment - I'm working on a solution using the UserApprovalHandler. I think it looks like the right direction and will address both this issue and SECOAUTH-205 .
        Hide
        Dave Syer added a comment -

        I finished the UserApprovalHandler changes. The default behaviour is the same as before but you can add <authorization-server user-approval-handler-ref=""/> and wire in a TokenServicesUserApprovalHandler. Sparklr2 does that and adds some custom behaviour to keep the old behaviour for the existing tests.

        Show
        Dave Syer added a comment - I finished the UserApprovalHandler changes. The default behaviour is the same as before but you can add <authorization-server user-approval-handler-ref=""/> and wire in a TokenServicesUserApprovalHandler. Sparklr2 does that and adds some custom behaviour to keep the old behaviour for the existing tests.
        Hide
        tony kerz added a comment -

        nice quick turnaround dave!

        i scanned the code quickly and noticed that you removed the resource-id component from the authentication-key,
        that simplifies things a bit, but at a glance, it seems like it might introduce an issue with a provider that serves up multiple resources?

        e.g. what if i go after resource-123, get a token, then go after resource-456, wouldn't it mistakenly pass me through based on the previous token?

        Show
        tony kerz added a comment - nice quick turnaround dave! i scanned the code quickly and noticed that you removed the resource-id component from the authentication-key, that simplifies things a bit, but at a glance, it seems like it might introduce an issue with a provider that serves up multiple resources? e.g. what if i go after resource-123, get a token, then go after resource-456, wouldn't it mistakenly pass me through based on the previous token?
        Hide
        Dave Syer added a comment -

        I think having the resource ids in the token store key is a mistake, but we'll probably have to use it a bit more to decide. The problem is that the resource ids are only known to the auth server, not to the client, so looking up a token based on information from a client cannot include a resource id. If resource servers are checking resource ids then the the attack / mistake that you describe fails. The only way for the client to get to resource-456 is to have it whitelisted by the auth server and then re-authenticate. We definitely need an API for revoking tokens so that this can actually happen in practice once client registration gets more dynamic. For now I don't think it's urgent and it's not related to this issue (I think). Open more tickets if you have problems.

        Show
        Dave Syer added a comment - I think having the resource ids in the token store key is a mistake, but we'll probably have to use it a bit more to decide. The problem is that the resource ids are only known to the auth server, not to the client, so looking up a token based on information from a client cannot include a resource id. If resource servers are checking resource ids then the the attack / mistake that you describe fails. The only way for the client to get to resource-456 is to have it whitelisted by the auth server and then re-authenticate. We definitely need an API for revoking tokens so that this can actually happen in practice once client registration gets more dynamic. For now I don't think it's urgent and it's not related to this issue (I think). Open more tickets if you have problems.
        Hide
        tony kerz added a comment -

        hi dave, i see what you are saying:

        it's the provider that associates those resource-id's with the client, as in:

          <oauth:client-details-service id="clientDetails">
            <oauth:client client-id="tonr" resource-ids="sparklr" authorized-grant-types="authorization_code" authorities="ROLE_CLIENT"
              scope="read,write" secret="secret" />
          </oauth:client-details-service>
        

        so as long as the client and it's associated resource-id's remains constant, including both in the key is redundant.

        now that i'm looking at it, it's not obvious to me how resource-id's are used by the provider.

        i see that they can be called out in this config:

          <oauth:resource-server id="resourceServerFilter" resource-id="sparklr" token-services-ref="tokenServices" />
        

        and they end up being referred to by OAuth2ProtectedResourceFilter, but thinking forward to dynamic client registration, it's not clear to me how it all fits together.

        for instance, will a client be given a pick list of resource-id's at registration time, etc?

        i agree though that the topic of resource-id's can arguably be separated from this issue.

        i'll find a better place to continue the discussion

        thanks again for your help on this!

        Show
        tony kerz added a comment - hi dave, i see what you are saying: it's the provider that associates those resource-id's with the client, as in: <oauth:client-details-service id= "clientDetails" > <oauth:client client-id= "tonr" resource-ids= "sparklr" authorized-grant-types= "authorization_code" authorities= "ROLE_CLIENT" scope= "read,write" secret= "secret" /> </oauth:client-details-service> so as long as the client and it's associated resource-id's remains constant, including both in the key is redundant. now that i'm looking at it, it's not obvious to me how resource-id's are used by the provider. i see that they can be called out in this config: <oauth:resource-server id= "resourceServerFilter" resource-id= "sparklr" token-services-ref= "tokenServices" /> and they end up being referred to by OAuth2ProtectedResourceFilter, but thinking forward to dynamic client registration, it's not clear to me how it all fits together. for instance, will a client be given a pick list of resource-id's at registration time, etc? i agree though that the topic of resource-id's can arguably be separated from this issue. i'll find a better place to continue the discussion thanks again for your help on this!

          People

          • Assignee:
            Dave Syer
            Reporter:
            sweta n
          • Votes:
            1 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: