Authorization to implement with Extensible Effect

Transcript

1. Authorization to implement with Extensible Effect Scala Matsuri 2023 @machuz &YUFOTJCMF
   & ff FDUͰ࣮૷͢ΔೝՄ
2. About me > Tsubasa Matsukawa - SWE at Alp.Inc @wing_007 @machuz ࣗݾ঺հ
3. Our Products > Scalebase This is software for launch up and managing and revenue management their subscription-based services. ΞϧϓͰ͸4DBMFCBTFͱ͍͏αϒεΫϦϓγϣϯ؅ཧͱ
   ܦӦ෼ੳͷ4BB4ϓϩμΫτΛఏڙ͍ͯ͠·͢
4. What is Authentication and Authorization? ೝূͱೝՄͱ͸ʁ
5. AuthN ~AutheNtication~ AuthN is to verify“who”the subject is. ೝূ͸ɺର৅͕ʮ୭ʯͰ͋Δ͔Λ֬ೝ͢Δ͜ͱͰ͢
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
7. This time, I will talk about authorization. ࠓճ͸ೝՄʹ͍͓ͭͯ࿩͠·͢
8. Some of the contents overlap with last year’s “Alp-original Eff peals”. ڈ೥ൃදͨ͠
   AΞϧϓͷ& ff ಠࣗ& ff FDUूA
   ͷҰͭͱͯ͠
   ঺հ͍ͯ͠ΔͷͰҰ෦ॏෳ͢Δ಺༰΋͋Γ·͢
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.
10. this is not much of a problem while the system is small and the requirements are simple. γεςϜ͕খ͘͞ɺཁ͕݅γϯϓϧͳ͏ͪ͸ɺ
    ͋·Γ໰୊ʹ͸ͳΓ·ͤΜɻ
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.
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
13. How complicated is it? ͲͷΑ͏ʹෳࡶͳͷͰ͠ΐ͏͔ʁ
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…
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 ݖݶ෇༩͞ΕΔܦ࿏͸ଟذʹΘͨΓ·͢ɻ
    ౷Ұతʹ؅ཧ͠ͳ͍ͱɺܦ࿏ຖʹ൑ఆ͕ඞཁʹͳΓɺ
    ϩδοΫ͕ڊେԽ͠·͢
16. There must be many other factors that complicate the process. ͜ΕΒҎ֎ʹ΋ෳࡶʹͳΔཁҼ͸͋ΔͰ͠ΐ͏
17. How can we avoid tight coupling between AuthZ and the unique requirements and handle AuthZ well? "VUI;ͱݸผཁ݅ͷີ݁߹Λආ͚ɺ
    "VUI;Λ͏·͘ѻ͏ʹ͸Ͳ͏͢Ε͹͍͍ͷ͔
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.
19. Components of Authz ೝՄͷߏ੒ཁૉ
20. Principal & Resource ೝՄ͸1SJODJQBMͱ3FTPVDF͔Βߏ੒͞Ε·͢ Principal Resource
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.
22. Principal & Resource has Authz attribute ͜ΕΒʹ͸ͦΕͧΕೝՄʹ࢖͏ଐੑΛ͍࣋ͨͤͯ·͢ "#"$ Principal Resource Policy Scope
23. Policy can also specify restrictions on specific resources 1PMJDZʹ͸ಛఆͷ3FTPVSDFʹର͢Δ੍ݶ΋ࢦఆՄೳͰ͢ Principal Resource Policy Scope ResourceId
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.
25. Policy can also specify restrictions on specific resources ઃఆ͞Ε͍ͯΔ4DPQFΛ
    Ϣʔβʔ͕ଐੑͱͯ͠อ͍࣋ͯ͠Δ৔߹ʹೝՄ͕௨Γ·͢ Principal Resource Policy Scope View:SomeResource View:SomeResource DBO
    WJFX ◦
26. Attributes of denial are given priority over those of permission ڋ൱ͷଐੑ͸ڐՄͷଐੑΑΓ༏ઌͯ͠ѻΘΕ·͢ Principal Resource Policy Scope View:SomeResource View:SomeResource Banned:All SFKFDU ✗
27. AuthZ Effect ͜ΕΒͷߏ੒ཁૉͱɺ& ff ͷࣜͱ࣮ߦΛ෼཭͢Δੑ࣭Λར༻ ͠ɺೝՄ& ff FDUΛ࣮૷͠·͢
28. ·ͣ͸"VUI;Λར༻͢ΔίϚϯυΛ"%5Ͱදݱ͠·͢ Design “AuthZ” effect > Commands that use AuthZ are expressed in ADT.
29. ࣍ʹίϚϯυΛΤϑΣΫτελοΫʹੵΉ
    ίϯετϥΫλΛ༻ҙ͠·͢ Design “AuthZ” effect > Next, we load the commands onto the effects stack constructor
30. ͜ΕͰೝՄͷ؅ཧଆɺґཔଆͷࣜΛ
    ߏஙͰ͖ΔΑ͏ʹͳΓ·ͨ͠ Build Program > The administrative and requesting side of the authorization equation It is now possible to construct.
31. ͜ͷΑ͏ʹಛఆͷϏδωεϩδοΫ΍
    σʔλྔͳͲ͕བྷΉΑ͏ͳ4QFDJ fi Dͳ৚݅ͱ΋߹੒ՄೳͰ͢ Build Program > Commands that use AuthZ are expressed in ADT.
32. Interpreter ࣍ʹ*OUFSQSFUFSͷ࣮૷Λߟ͑ͯΈ·͢
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
34. In this way, the gRPC Client will query Authz-ctx via gRPC Client. Implement Interpreter ͜ͷΑ͏ʹ࣮૷͸͢΂ͯγϯϓϧʹH31$$MJFOUܦ༝Ͱ
    "VUI;DUYʹ໰͍߹Θ͍ͤͯ·͢
35. In this way, we try to keep the interests of authorization, which tend to combine We try to keep them sparse. ೝՄଐੑͷ؅ཧͱ4DPQFͱଐੑಥ߹൑ఆ෦෼ΛผίϯςΩετ ʹ੾Γग़͢͜ͱͰɺೝՄͷؔ৺ࣄΛૄʹอͭΑ͏ʹ͍ͯ͠·͢
36. Client-side authorization settings ࠷ޙʹɺΫϥΠΞϯτଆͰ
    ͲͷΑ͏ʹೝՄΛઃఆ͢Δ͔͝঺հ͠·͢
37. Setting up in a nutshell is a difficult problem! ೝՄͷઃఆ΋·ͨ೉͍͠໰୊Ͱ͢ɻ
    ཁ݅ͱີ݁߹͠΍͘͢ɺϩδοΫͰҙࣝͨ͋͘͠Γ·ͤΜ
38. Resource exists in various places, making it difficult to handle in a unified handling. ೝՄͷର৅Ͱ͋Δ3FTPVSDFͷ4DPQF͕͞·͟·ͳ৔ॴʹ
    ଘࡏ͢ΔͨΊɺ౷ҰతͳϋϯυϦϯά͕೉͍͠ੑ࣭΋͋Γ·͢
39. Solutions ͜ΕΛએݴతͳ4DPQFઃఆɺ4UBUFϞφυɺΠϯλϓϦλ࣮ߦ ࣌ʹೝՄνΣοΫΛڧ੍తʹ૊ΈࠐΉ͜ͱͰղܾͰ͖·ͨ͠ > Declarative scope setting > State monad > Enforce authorization checks at interpreter execute
40. Declarative scope setting υϝΠϯϞσϧͷ*%౳ʹείʔϓΛ෇༩͢Δ Assign scope to domain model IDs, etc…
41. State monad ಠࣗΤϑΣΫτͰɺ
    ઃఆͨ͠είʔϓΛ4UBUF
    .POBEʹQVU͠·͢ Put the scope set by the original effect to State
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.
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.
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]
45. By using this, the authorization for the entire process only needs to be checked once! ͜ΕΛར༻͢Δ͜ͱͰɺ
    ॲཧશମͷೝՄΛҰճͷνΣοΫͰࡁ·ͤΔ͜ͱ͕Ͱ͖·ͨ͠
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
47. ࣜͷධՁ௚લʹೝՄνΣοΫͷࣜΛ࢓ࠐΊΔͷͰɺ
    ࣜશମʹؚ·ΕΔೝՄଐੑʹର͢Δ൑ఆ͕ՄೳͰ͢ Add authorization checks to the end of the expression > In the assembled expression, The authorization attributes necessary for execution are encapsulated.
48. Enforce authorization checks at interpreter execute #BUDIͳͲɺݖݶνΣοΫΛলུ͍ͨ͠έʔεͰ͸
    লུͰ͖·͢ Can be omitted in cases where you want to omit permission checks, such as in batches
49. Enforce authorization flow ೝՄͷద༻ϑϩʔ 
    &YQSFTTJPO
    "TTFNCMZ
    1IBTF %FGJOF
    B
    DPNNBOE
    UP
    TFU
    UIF
    SFRVJSFE
    TDPQF
    UP
    4UBUF
    BU
    BOZ
    QPJOU
    JO
    UIF
    DPEF
    CBTF
    :PV
    XJMM
    IBWF
    BO
    FYQSFTTJPO
    XJUI
    UIF
    TDPQF
    ZPV
    OFFE
    UP
    FYFDVUF
    JU 
    $BMM
    JOUFSQSFUFS
    1IBTF 
    3VO
    JOUFSQSFUFS
    1IBTF QSPHSBNSVO authzInterpreter.run( program << requestAuthzScope(principalId) ) WBM
    QSPHSBN
    &GG<3
    "> Stack State[List[ActionCompose], A] & others(DB,Task,Either, etc..) 1BTTFT
    BO
    FYQSFTTJPO
    XJUI
    TDPQF
    UP
    UIF
    JOUFSQSFUFS
    *ODPSQPSBUF
    BVUIPSJ[BUJPO
    SFRVFTU
    DPNNBOET
    XIFO
    QBTTJOH
    5IJT
    BMMPXT
    VT
    UP
    FOGPSDF
    UIF
    BVUIPSJ[BUJPO
    SFRVFTU
    XIFO
    PCUBJOJOH
    s&GG<3 ">
    
    "s 8IFO
    UIF
    rSFRVFTU"VUI[4DPQF
    DPNNBOE
    JT
    FWBMVBUFE
    B
    BMMPX EFOZ
    EFDJTJPO
    JT
    NBEF
    CBTFE
    PO
    UIF
    TDPQF
    TFU
    BOE
    QFSNJTTJPOT
    BTTPDJBUFE
    XJUI
    UIF
    QSJODJQBM
    *G
    UIF
    EFDJTJPO
    JT
    EFOZ
    BO
    &JUIFSMFGU
    JT
    BEEFE
    UP
    UIF
    FGGFDU
    TUBDL
    BOE
    UIF
    DPNQVUBUJPO
    JT
    TUPQQFE
    for { state <- get[U, List[ActionComposing]] attachedPolicy <- showPolicy(principalId) attachedAction = attachedPolicy.policies.map(_.action) …
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.
51. ‘Eff’ is Good! 👍👍 & ff ͸͍͍ͧʂ
52. Thanks!