$30 off During Our Annual Pro Sale. View Details »

Authorization to implement with Extensible Effect

Authorization to implement with Extensible Effect

machu
PRO

April 15, 2023
Tweet

More Decks by machu

Other Decks in Programming

Transcript

  1. Authorization to implement
    with Extensible Effect
    Scala Matsuri 2023


    @machuz
    &YUFOTJCMF&
    ff
    FDUͰ࣮૷͢ΔೝՄ

    View Slide

  2. About me
    > Tsubasa Matsukawa


    - SWE at Alp.Inc
    @wing_007
    @machuz
    ࣗݾ঺հ

    View Slide

  3. Our Products
    > Scalebase


    This is software for launch up and
    managing and revenue management
    their subscription-based services.
    ΞϧϓͰ͸4DBMFCBTFͱ͍͏αϒεΫϦϓγϣϯ؅ཧͱ
    ܦӦ෼ੳͷ4BB4ϓϩμΫτΛఏڙ͍ͯ͠·͢

    View Slide

  4. What is Authentication
    and Authorization?
    ೝূͱೝՄͱ͸ʁ

    View Slide

  5. AuthN ~AutheNtication~
    AuthN is to verify“who”the subject is.


    ೝূ͸ɺର৅͕ʮ୭ʯͰ͋Δ͔Λ֬ೝ͢Δ͜ͱͰ͢

    View Slide

  6. AuthZ ~AuthoriZation ~
    AuthZ is a control that allows any subject to allow
    or deny action on any resource.
    ೝՄ͸ɺ`೚ҙͷର৅`͕b೚ҙͷϦιʔε`ʹରͯ͠ߦ͏
    ΞΫγϣϯͷڐՄڋ൱Λ੍ޚ͢Δ͜ͱͰ͢
    Principal
    Resource
    "DUJPO
    "MMPX %FOZ

    View Slide

  7. This time,


    I will talk about
    authorization.
    ࠓճ͸ೝՄʹ͍͓ͭͯ࿩͠·͢

    View Slide

  8. Some of the contents
    overlap with last year’s


    “Alp-original Eff peals”.
    ڈ೥ൃදͨ͠AΞϧϓͷ&
    ff
    ಠࣗ&
    ff
    FDUूAͷҰͭͱͯ͠
    ঺հ͍ͯ͠ΔͷͰҰ෦ॏෳ͢Δ಺༰΋͋Γ·͢

    View Slide

  9. Authorization is complex and
    coverage is wide-ranging
    Presenter
    Controller
    Repository(DB etc..)
    UseCase
    Domain
    Masking item
    Execute endpoint
    Filter resource


    read/write auhorization
    Execute UseCase


    Ramification domainLogic
    Execute domainLogic
    ೝՄ͸ద༻ൣғ͕޿͘ɺཁ݅࣍ୈͰ͸1SFTFOUFSd%PNBJO·Ͱ
    Өڹ͠͏Δɺͱͯ΋ෳࡶͳ֓೦Ͱ͢
    > Because authz is abstract, it is often implemented in close coupling with concrete
    requirements, resulting in inflexibility.

    View Slide

  10. this is not much of a problem
    while the system is small and
    the requirements are simple.
    γεςϜ͕খ͘͞ɺཁ͕݅γϯϓϧͳ͏ͪ͸ɺ
    ͋·Γ໰୊ʹ͸ͳΓ·ͤΜɻ

    View Slide

  11. Simple-Case
    ͨͱ͑͹ɺೝূ͕௨Ε͹γεςϜ্ͷ͢΂ͯͷૢ࡞Λ
    ڐՄ͢Δ৔߹ͳͲ͸ೝՄΛҙࣝ͢Δඞཁ΋ͳ͍Ͱ͠ΐ͏ɻ
    => whatever you can do
    > For example, if you want to allow all operations on a
    system as long as AuthN is given, you do not need to be
    aware of the Authz.

    View Slide

  12. > It can get very complicated if you want to delegate some of
    the privileges or allow/deny operations through multiple paths.
    ݖݶͷҰ෦Λҕৡͨ͠Γɺෳ਺ͷܦ࿏Ͱૢ࡞ΛڐՄڋ൱ͨ͠
    ͍৔߹͸ɺඇৗʹෳࡶʹͳΔՄೳੑ͕͋Γ·͢ɻ
    =>
    decision
    complicated-Case
    &&
    What action?


    What resources are targeted?


    Paid for?


    has Manual Permission?


    is Developer?


    is BAN?


    etc…
    or
    user|token

    View Slide

  13. How complicated is it?
    ͲͷΑ͏ʹෳࡶͳͷͰ͠ΐ͏͔ʁ

    View Slide

  14. Case1:


    Multi principals
    > When it becomes necessary to manage the permissions
    of multiple principals (users, API tokens, operators, etc...),
    without a unified management mechanism, similar
    implementations will increase.
    Authz attribute


    associated with the API key
    Authz attribute associated
    with the User
    ෳ਺ͷϓϦϯγύϧ͕ଘࡏ͢Δࡍɺ౷Ұతʹ؅ཧ͍ͯ͠ͳ͍ͱ
    ࣅͨΑ͏ͳϩδοΫ͕૿͑ͯ͠·͍·͢
    etc…

    View Slide

  15. Case2:


    Multiple authorization paths
    > There are a wide variety of paths to be authorized.


    > If not managed in a unified manner, decisions must be
    made for each path, and the logic becomes huge!
    AuthZ attribute A
    - When a bill is paid successfully


    - When delegating to an API key


    - When creating a user


    - When manually granted
    ݖݶ෇༩͞ΕΔܦ࿏͸ଟذʹΘͨΓ·͢ɻ
    ౷Ұతʹ؅ཧ͠ͳ͍ͱɺܦ࿏ຖʹ൑ఆ͕ඞཁʹͳΓɺ
    ϩδοΫ͕ڊେԽ͠·͢

    View Slide

  16. There must be many other
    factors that complicate the
    process.
    ͜ΕΒҎ֎ʹ΋ෳࡶʹͳΔཁҼ͸͋ΔͰ͠ΐ͏

    View Slide

  17. How can we avoid tight coupling
    between AuthZ and the unique
    requirements and handle AuthZ well?
    "VUI;ͱݸผཁ݅ͷີ݁߹Λආ͚ɺ
    "VUI;Λ͏·͘ѻ͏ʹ͸Ͳ͏͢Ε͹͍͍ͷ͔

    View Slide

  18. Separation of management and client of
    judgment.
    զʑ͸͜ͷෳࡶੑʹbೝՄͷ؅ཧଆ`ͱ
    b൑ఆΛґཔ͢Δଆ`Λ෼͚Δ͜ͱͰରԠ͢Δ͜ͱʹ͠·ͨ͠
    Management
    ·Principal(ID&Type)


    ·Authority attributes


    ·Target resources
    Judgement Client
    The decision is made by recognizing and
    querying the principal's ID, required
    authorization attributes, and resource ID to
    obtain results.


    It should also be able to combine the
    results with the results of proprietary
    requirement-specific logic.
    Mapping of the following elements.
    State of this mapping.
    ·Allocation path


    ·Term


    ·enable/disable
    With this information, return a decision
    request from the client.

    View Slide

  19. Components of Authz
    ೝՄͷߏ੒ཁૉ

    View Slide

  20. Principal & Resource
    ೝՄ͸1SJODJQBMͱ3FTPVDF͔Βߏ੒͞Ε·͢
    Principal Resource

    View Slide

  21. Principal? Resource?
    1SJODJQBMೝՄର৅
    3FTPVSDFೝՄର৅ͷૢ࡞ʹӨڹ͢Δର৅
    > Principal


    - Authorization target


    ex. User, AcessToken etc…


    > Resource


    - object that affect principal operation.


    - What is treated as Principal may also be treated as Resource.




    View Slide

  22. Principal & Resource has Authz attribute
    ͜ΕΒʹ͸ͦΕͧΕೝՄʹ࢖͏ଐੑΛ͍࣋ͨͤͯ·͢ "#"$

    Principal Resource
    Policy Scope

    View Slide

  23. Policy can also specify restrictions on
    specific resources
    1PMJDZʹ͸ಛఆͷ3FTPVSDFʹର͢Δ੍ݶ΋ࢦఆՄೳͰ͢
    Principal Resource
    Policy Scope
    ResourceId

    View Slide

  24. Policy ? Scope ?
    1PMJDZ͸1SJODJQBMʹ෇༩͞ΕΔೝՄଐੑ
    4DPQF͸3FTPVSDFʹ෇༩͞ΕΔೝՄ৘ใ
    > Policy


    - Authorization attribute assigned to Principal.


    - In addition to authorization information, it has resource id and other
    information used for id-based filters.


    - Store in Database.


    > Scope


    - Authorization attribute assigned to Resource.


    - Describe in code.


    View Slide

  25. Policy can also specify restrictions on
    specific resources
    ઃఆ͞Ε͍ͯΔ4DPQFΛ
    Ϣʔβʔ͕ଐੑͱͯ͠อ͍࣋ͯ͠Δ৔߹ʹೝՄ͕௨Γ·͢
    Principal Resource
    Policy Scope
    View:SomeResource
    View:SomeResource
    DBOWJFX

    View Slide

  26. Attributes of denial are given priority
    over those of permission
    ڋ൱ͷଐੑ͸ڐՄͷଐੑΑΓ༏ઌͯ͠ѻΘΕ·͢
    Principal Resource
    Policy Scope
    View:SomeResource
    View:SomeResource
    Banned:All
    SFKFDU

    View Slide

  27. AuthZ Effect
    ͜ΕΒͷߏ੒ཁૉͱɺ&
    ff
    ͷࣜͱ࣮ߦΛ෼཭͢Δੑ࣭Λར༻
    ͠ɺೝՄ&
    ff
    FDUΛ࣮૷͠·͢

    View Slide

  28. ·ͣ͸"VUI;Λར༻͢ΔίϚϯυΛ"%5Ͱදݱ͠·͢
    Design “AuthZ” effect
    > Commands that use AuthZ are expressed in ADT.

    View Slide

  29. ࣍ʹίϚϯυΛΤϑΣΫτελοΫʹੵΉ
    ίϯετϥΫλΛ༻ҙ͠·͢
    Design “AuthZ” effect
    > Next, we load the commands onto the effects stack constructor

    View Slide

  30. ͜ΕͰೝՄͷ؅ཧଆɺґཔଆͷࣜΛ
    ߏஙͰ͖ΔΑ͏ʹͳΓ·ͨ͠
    Build Program
    > The administrative and requesting side of the authorization equation
    It is now possible to construct.

    View Slide

  31. ͜ͷΑ͏ʹಛఆͷϏδωεϩδοΫ΍
    σʔλྔͳͲ͕བྷΉΑ͏ͳ4QFDJ
    fi
    Dͳ৚݅ͱ΋߹੒ՄೳͰ͢
    Build Program
    > Commands that use AuthZ are expressed in ADT.

    View Slide

  32. Interpreter
    ࣍ʹ*OUFSQSFUFSͷ࣮૷Λߟ͑ͯΈ·͢

    View Slide

  33. The premise is to adopt a monolith of modules and implementation
    of the interpreter is a query to AuthZ-ctx.
    Presenter
    Controller
    Adapter


    UseCase
    Domain
    Lib
    Subscription-ctx
    Presenter
    Controller
    Adapter


    UseCase
    Domain
    Lib
    Authz-ctx
    judgement
    request
    Prerequisite
    લఏͱͯ͠ɺฐࣾ͸ϞδϡϥϞϊϦεΛ࠾༻͓ͯ͠Γɺ
    ΠϯλϓϦλͷ࣮૷͸"VUI;DUY΁ͷ໰͍߹ΘͤͰ͢
    Presenter
    Controller
    Adapter


    UseCase
    Domain
    Lib
    Payment-ctx
    add policy
    request

    View Slide

  34. In this way, the gRPC Client will query Authz-ctx via gRPC Client.
    Implement Interpreter
    ͜ͷΑ͏ʹ࣮૷͸͢΂ͯγϯϓϧʹH31$$MJFOUܦ༝Ͱ
    "VUI;DUYʹ໰͍߹Θ͍ͤͯ·͢

    View Slide

  35. In this way, we try to keep the
    interests of authorization, which tend
    to combine We try to keep them
    sparse.
    ೝՄଐੑͷ؅ཧͱ4DPQFͱଐੑಥ߹൑ఆ෦෼ΛผίϯςΩετ
    ʹ੾Γग़͢͜ͱͰɺೝՄͷؔ৺ࣄΛૄʹอͭΑ͏ʹ͍ͯ͠·͢

    View Slide

  36. Client-side authorization
    settings
    ࠷ޙʹɺΫϥΠΞϯτଆͰ
    ͲͷΑ͏ʹೝՄΛઃఆ͢Δ͔͝঺հ͠·͢

    View Slide

  37. Setting up in a nutshell
    is a difficult problem!
    ೝՄͷઃఆ΋·ͨ೉͍͠໰୊Ͱ͢ɻ
    ཁ݅ͱີ݁߹͠΍͘͢ɺϩδοΫͰҙࣝͨ͋͘͠Γ·ͤΜ

    View Slide

  38. Resource exists in various
    places, making it difficult to
    handle in a unified handling.
    ೝՄͷର৅Ͱ͋Δ3FTPVSDFͷ4DPQF͕͞·͟·ͳ৔ॴʹ
    ଘࡏ͢ΔͨΊɺ౷ҰతͳϋϯυϦϯά͕೉͍͠ੑ࣭΋͋Γ·͢

    View Slide

  39. Solutions
    ͜ΕΛએݴతͳ4DPQFઃఆɺ4UBUFϞφυɺΠϯλϓϦλ࣮ߦ
    ࣌ʹೝՄνΣοΫΛڧ੍తʹ૊ΈࠐΉ͜ͱͰղܾͰ͖·ͨ͠
    > Declarative scope setting


    > State monad


    > Enforce authorization checks at interpreter execute


    View Slide

  40. Declarative scope setting
    υϝΠϯϞσϧͷ*%౳ʹείʔϓΛ෇༩͢Δ
    Assign scope to domain model IDs, etc…


    View Slide

  41. State monad
    ಠࣗΤϑΣΫτͰɺ
    ઃఆͨ͠είʔϓΛ4UBUF.POBEʹQVU͠·͢
    Put the scope set by the original effect to State

    View Slide

  42. State monad
    είʔϓ͸ࢦఆͷܕʹแΊ͹
    ࣗಈͰΤϑΣΫτελοΫʹੵ·ΕΔΑ͏ʹ͠·ͨ͠

    TDBMB
    fi
    YͰܕͷࢦఆ͕࿙Ε͍ͯΕ͹ίϯύΠϧΤϥʔʹ͠·͢
    > By setting the return value of the interface to the specified type, the scope
    is automatically loaded onto the effects stack.


    > If the type specification is omitted, `scalafix` will generate a compile error.


    View Slide

  43. ͜ͷ࢓૊ΈʹΑͬͯɺࣜʹ͸࣮ߦʹඞཁͳೝՄείʔϓ͕಺แ
    ͞Ε·͢ɻ͜ΕͱϢʔβʔͷଐੑͰ൑ఆΛ͠·͢
    Build Program
    &GG<3 "> "QJ,FZ3FBE
    $POUSBDU"MM
    #JMMJOH3FBE
    $POUSBDU"MM
    > In the assembled expression, The authorization scope necessary for
    execution are encapsulated.


    > This and the user's attributes are used to determine.

    View Slide

  44. State monad
    ֤૚ʹލͬͨೝՄείʔϓ΋ͭͷ4UBUFͰ؅ཧͰ͖·͢
    > This allows for the management of authorization scopes across all tiers
    in a single State.


    Presenter
    Controller
    Repository(DB etc..)
    UseCase
    Domain
    Set Scope A
    Set Scope B
    Set Scope C,D
    Set Scope E
    Set Scope F
    State[List[A,B,C,D,E,F], X]

    View Slide

  45. By using this, the authorization
    for the entire process only
    needs to be checked once!
    ͜ΕΛར༻͢Δ͜ͱͰɺ
    ॲཧશମͷೝՄΛҰճͷνΣοΫͰࡁ·ͤΔ͜ͱ͕Ͱ͖·ͨ͠

    View Slide

  46. Add authorization checks to the
    end of the expression
    &
    ff
    FDUΛΠϯλϓϦλʹ౉͢खલͰɺ
    1SJODJQBMͷݖݶϦΫΤετΛڬΈ·͢
    Before executing your own effects


    Interrupt the authorization request of the Principal

    View Slide

  47. ࣜͷධՁ௚લʹೝՄνΣοΫͷࣜΛ࢓ࠐΊΔͷͰɺ
    ࣜશମʹؚ·ΕΔೝՄଐੑʹର͢Δ൑ఆ͕ՄೳͰ͢
    Add authorization checks to the
    end of the expression
    > In the assembled expression, The authorization attributes necessary
    for execution are encapsulated.

    View Slide

  48. Enforce authorization checks at
    interpreter execute
    #BUDIͳͲɺݖݶνΣοΫΛলུ͍ͨ͠έʔεͰ͸
    লུͰ͖·͢
    Can be omitted in cases where you want to omit permission checks,
    such as in batches

    View Slide

  49. Enforce authorization flow
    ೝՄͷద༻ϑϩʔ
    &YQSFTTJPO"TTFNCMZ1IBTF
    %FGJOFBDPNNBOEUPTFUUIF
    SFRVJSFETDPQFUP4UBUFBUBOZ
    QPJOUJOUIFDPEFCBTF
    :PVXJMMIBWFBOFYQSFTTJPOXJUI
    UIFTDPQFZPVOFFEUPFYFDVUFJU
    $BMMJOUFSQSFUFS1IBTF 3VOJOUFSQSFUFS1IBTF
    QSPHSBNSVO

    authzInterpreter.run(


    program << requestAuthzScope(principalId)


    )
    WBMQSPHSBN&GG<3 ">
    Stack State[List[ActionCompose], A]


    & others(DB,Task,Either, etc..)
    1BTTFTBOFYQSFTTJPOXJUITDPQF
    UPUIFJOUFSQSFUFS
    *ODPSQPSBUFBVUIPSJ[BUJPOSFRVFTU
    DPNNBOETXIFOQBTTJOH
    5IJTBMMPXTVTUPFOGPSDFUIF
    BVUIPSJ[BUJPOSFRVFTUXIFO
    PCUBJOJOHs&GG<3 ">"s
    8IFOUIFrSFRVFTU"VUI[4DPQF
    DPNNBOEJTFWBMVBUFE BBMMPX
    EFOZEFDJTJPOJTNBEFCBTFEPOUIF
    TDPQFTFUBOEQFSNJTTJPOT
    BTTPDJBUFEXJUIUIFQSJODJQBM
    *GUIFEFDJTJPOJTEFOZ BO
    &JUIFSMFGUJTBEEFEUPUIFFGGFDU
    TUBDLBOEUIFDPNQVUBUJPOJT
    TUPQQFE
    for {
    state <- get[U, List[ActionComposing]]
    attachedPolicy <- showPolicy(principalId)
    attachedAction = attachedPolicy.policies.map(_.action)

    View Slide

  50. ͜ΕΒͷϝϦοτΛڗडͰ͖ΔΑ͏ʹͳΓ·ͨ͠
    Pros
    > Scopes set up in various places can be collected by State monad.


    > Can create a situation where an authorization check is mandatory to
    evaluate an expression.


    > By placing the permission check before execution, it is no longer
    necessary to separate implementations based on whether permission
    checks are required or not.

    View Slide

  51. ‘Eff’ is Good! 👍👍
    &
    ff
    ͸͍͍ͧʂ

    View Slide

  52. Thanks!

    View Slide