Uploaded image for project: 'Spring Security OAuth'
  1. Spring Security OAuth
  2. SECOAUTH-129

Remember authorization decisions for individual client/user combinations

    Details

    • Type: New Feature
    • Status: Resolved
    • Priority: 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
        david_syer 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
        david_syer 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
        david_syer 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
        david_syer 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_k 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_k 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
        david_syer 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
        david_syer 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_k 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_k 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:
            david_syer Dave Syer
            Reporter:
            sweta sweta n
          • Votes:
            1 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development