Uploaded image for project: 'OpenAM'
  1. OpenAM
  2. OPENAM-14676

DOCS: Clarify the meaning of OAuth2 Dynamic Scopes functionality

    Details

    • Sprint:
      2019.5 - Scissors, AM 2019.8 - Crank, AM 2019.9 - Crane
    • Story Points:
      3
    • Needs backport:
      No
    • Needs QA verification:
      No
    • Functional tests:
      No
    • Are the reproduction steps defined?:
      No (add reasons in the comment)

      Description

      In docs, Dynamic scopes is presented as follows:

      Dynamically. You configure an OAuth 2.0 client with a comprehensive list of scopes and resource owners authenticate against it. When AM receives a request for scopes, AM's Authorization Service grants or denies access scopes dynamically by evaluating authorization policies at runtime. Therefore, two different users requesting scopes A and B to the same client can receive different scopes based on policy conditions. 

      With a further comment in the AuthZ guide:

      When OAuth 2.0 policies are configured, default scopes are granted in the following situations as long as they are configured in a policy which passes policy evaluation:

      • When no scope is requested
      • When default scopes are requested

      The second comment specifically made me understand that scopes were granted only if there was a policy granting them, and I understood it as having the Authorization server is the policy decision point. That is in line with the way we use the policy engine to design authz policies and how IG and policy agents understand it too. If no policies is defined, access is denied. That is in line with the comment above. However I found out that the comment in the docs above is only valid for some of the flows (e.g. ROPC) but not others (the authZ code will return the scope if consent is given, even if there are no policies defined for it).

      This is because the policy engine is being used differently in the context of Dynamic scopes. Talking to engineering, the following comment was made:

      the dynamic scopes is intended to be used to deduce consent status. As such, an allow result means consent is granted, a deny result means consent is denied. Neither allow nor deny means it is down to the resource owner to decide on whether the consent is granted,* i.e. "normal" behaviour without policies being used*
      
      In other word :
       Case A: Policy is defined with GRANT=allow
       Case A.1) User is matching policy (subject tab)
       — > scope will be removed from consent page as "granted scope", but added to access_token/id_token.
       Case A.2) User is matching policy (subject tab) & Allow Clients to Skip Consent ... 
       — > scope will be added to access_token/id_token.
       Case A.3) User is not matching policy (subject tab)
       — > scope will be shown and user gets to decide whether to give permission or not. 
       Case A.4) User is not matching policy (subject tab) & Allow Clients to Skip Consent
       — > scope will be added to access_token/id_token automatically.Case B:
      
      Policy is defined with GRANT=deny
       Case B.1) User is matching policy (subject tab)
       — > scope will be removed from consent page and access_token/id_token. (it's not working at the mo so this will be fixed via OPENAM-14548)
       Case B.2) User is matching policy (subject tab) & Allow Clients to Skip Consent ... 
       — > scope will be removed from access_token/id_token. (it's not working at the mo so this will be fixed via OPENAM-14548)
       Case B.3) User is not matching policy (subject tab)
       — > scope will be shown and user gets to decide whether to give permission or not. 
       Case B.4) User is not matching policy (subject tab) & Allow Clients to Skip Consent
       — > scope will be added to access_token/id_token automatically
      

      I believe the above needs clarifying in the docs to avoid the confusion.

      There is also a need to document the difference in outcome depending on the flow. The difference is due to the fact that some flows don't let the user express their consent (ROPC).

      For example:

      • Create a OAuth2 environment with scopes read and write
      • Enable dynamic scope
      • Create one policy to deny the 'write' scope to users who are not part of the 'editor'
      • Request the scopes 'read' and 'write'

      1) As far as I can see, with ROPC you will never get the scopes as there is no consent possible and no policy to imply consent for those.

      2) With AuthZ code, the RO will see a consent screen with read if not an editor, and with read and write if they are an editor and the scopes will be granted if consent is given.

      Note that I haven't checked all flows and configuration. 

       

        Attachments

          Activity

            People

            • Assignee:
              cristina.herraz Cristina Herraz
              Reporter:
              nathalie.hoet Nathalie Hoet
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: