Authorization to implement with Extensible Effect

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