Designing with capabilities (DDD-EU 2017)
8 likes8,761 views
The document discusses the relationship between security and design in API development, emphasizing the concept of capabilities in managing authority and access control. It highlights the principle of least authority (POLA) and provides examples of capability-based API designs to reduce coupling and enhance security. Additionally, it addresses design considerations within bounded contexts and the importance of intention-revealing interfaces for effective software architecture.
![Tic-Tac-Toe HATEOAS
[
{ "move": "Play (Left,Top)",
"rel": "LeftTop",
"href": "/move/ec03def5-7ea8-4ac3-baf7-b290582cd3f2" },
{ "move": "Play (Left, Middle)",
"rel": "Left Middle",
"href": "/move/d4532ca0-4e61-4fae-bbb1-fc11d4e173df" },
{ "move": "Play (Left, Bottom)",
"rel": "Left Bottom",
"href": "/move/fe1bfa98-e77b-4331-b99b-22850d35d39e" }
...
]](https://image.slidesharecdn.com/designingwithcapabilities-dddeu2017-170217180501/85/Designing-with-capabilities-DDD-EU-2017-44-320.jpg)
![public class CustomerController : ApiController
{
readonly ICustomerDb _db;
public CustomerController(ICustomerDb db)
{
_db = db;
}
[Route("customers/{customerId}")]
[HttpGet]
public IHttpActionResult Get(int customerId)
{
var custId = new CustomerId(customerId);
var cust = _db.GetProfile(custId);
var dto = DtoConverter.CustomerToDto(cust);
return Ok(dto);
}](https://image.slidesharecdn.com/designingwithcapabilities-dddeu2017-170217180501/85/Designing-with-capabilities-DDD-EU-2017-54-320.jpg)
![public class CustomerController : ApiController
{
Func<CustomerId,CustomerProfile> _readCust;
public CustomerController(Func<..> readCust)
{
_readCust = readCust;
}
[Route("customers/{customerId}")]
[HttpGet]
public IHttpActionResult Get(int customerId)
{
var custId = new CustomerId(customerId);
var cust = _readCust(custId);
var dto = DtoConverter.CustomerToDto(cust);
return Ok(dto);
}](https://image.slidesharecdn.com/designingwithcapabilities-dddeu2017-170217180501/85/Designing-with-capabilities-DDD-EU-2017-59-320.jpg)
![public class CustomerController : ApiController
{
[Route("customers/{customerId}")]
[HttpGet]
public IHttpActionResult Get(int customerId)
{
var custId = new CustomerId(customerId);
var readCust = authorizer.GetReadCustCap(custId);
if (readCust != null)
{
var cust = readCust();
var dto = DtoConverter.CustomerToDto(cust);
return Ok(dto);
}
else
// return error
}](https://image.slidesharecdn.com/designingwithcapabilities-dddeu2017-170217180501/85/Designing-with-capabilities-DDD-EU-2017-63-320.jpg)
Designing with capabilities (DDD-EU 2017)
- 1. Designing with capabilities (DDD Europe 2017) @ScottWlaschin fsharpforfunandprofit.com/cap
- 4. Topics âą What does security have to do with design? âą Introducing capabilities âą API design with capabilities âą Design consequences of using capabilities âą Transforming capabilities for business rules âą Delegating authority using capabilities
- 5. WHAT DOES SECURITY HAVETO DO WITH DESIGN?
- 7. Sed ut perspiciatis unde omnis iste natus error sit voluptatem accusantium doloremque laudantium, totam rem aperiam, eaque ipsa quae ab illo inventore veritatis et quasi architecto beatae vitae dicta sunt explicabo. Nemo enim ipsam voluptatem quia voluptas sit aspernatur aut odit aut fugit, sed quia consequuntur magni dolores eos qui ratione voluptatem sequi nesciunt. Neque porro quisquam est, qui dolorem ipsum quia dolor sit amet, consectetur, adipisci velit, sed quia non numquam eius modi tempora incidunt ut labore et dolore magnam aliquam quaerat voluptatem. Ut enim ad minima veniam, quis nostrum exercitationem ullam corporis suscipit laboriosam, nisi ut aliquid ex ea commodi consequatur? Quis autem vel eum iure reprehenderit qui in ea voluptate velit esse quam nihil molestiae consequatur, Temporibus autem quibus Dacei Megasystems Tech Inc necessitatibust aut officiis debitis auteo 2799 E Dragam Suite 7 quisquam saepe Itaque enieti Los Angeles CA 90002 ut et voluptates repudiandae sint et molestiae non recusandae. Itaque earum rerum hic tenetur a sapiente delectus, ut aut reiciendis voluptatibus maiores alias consequatur aut perferendis doloribus asperiores repellat. Neque porro quisquam est, qui dolorem ipsum quia dolor sit amet, consectetur, adipisci velit, sed quia non numquam eius modi tempora incidunt ut labore et dolore magnam aliquam quaerat voluptatem. Ut enim ad minima veniam, quis nostrum exercitationem ullam corporis suscipit laboriosam, nisi ut aliquid ex ea commodi consequatur? Please deliver this letter A counterexample
- 8. Sed ut perspiciatis unde omnis iste natus error sit voluptatem accusantium doloremque laudantium, totam rem aperiam, eaque ipsa quae ab illo inventore veritatis et quasi architecto beatae vitae dicta sunt explicabo. Nemo enim ipsam voluptatem quia voluptas sit aspernatur aut odit aut fugit, sed quia consequuntur magni dolores eos qui ratione voluptatem sequi nesciunt. Neque porro quisquam est, qui dolorem ipsum quia dolor sit amet, consectetur, adipisci velit, sed quia non numquam eius modi tempora incidunt ut labore et dolore magnam aliquam quaerat voluptatem. Ut enim ad minima veniam, quis nostrum exercitationem ullam corporis suscipit laboriosam, nisi ut aliquid ex ea commodi consequatur? Quis autem vel eum iure reprehenderit qui in ea voluptate velit esse quam nihil molestiae consequatur, Temporibus autem quibus Dacei Megasystems Tech Inc necessitatibust aut officiis debitis auteo 2799 E Dragam Suite 7 quisquam saepe Itaque enieti Los Angeles CA 90002 ut et voluptates repudiandae sint et molestiae non recusandae. Itaque earum rerum hic tenetur a sapiente delectus, ut aut reiciendis voluptatibus maiores alias consequatur aut perferendis doloribus asperiores repellat. Neque porro quisquam est, qui dolorem ipsum quia dolor sit amet, consectetur, adipisci velit, sed quia non numquam eius modi tempora incidunt ut labore et dolore magnam aliquam quaerat voluptatem. Ut enim ad minima veniam, quis nostrum exercitationem ullam corporis suscipit laboriosam, nisi ut aliquid ex ea commodi consequatur? Please deliver this letter Itâs not just about security... ...hiding irrelevant information is good design!
- 9. David Parnas, 1971 âą If you make information available: â Programmers canât help but make use of it â Even if not in best interests of the design âą Solution: â Donât make information available!
- 10. Canât do anything Just right Unnecessary coupling In the large: Bounded Contexts In the small: Interface Segregation Principle Software Design Spectrum Too much information availableToo little information available
- 11. Canât get your work done Too much information available Just right Potential for abuse Principle of Least Authority (POLA) Too little information available Security spectrum
- 12. Ak.a. Minimize your surface area (to reduce chance of abuse) Good Software Design Intention-revealing interface Minimize coupling Make dependencies explicit Good Security Principle of Least Authority (POLA) Ak.a. Minimize your surface area (expose only desired behavior)
- 13. Good security => Good design Good design => Good security
- 14. Security-aware design âą "Authority" = what can you do at any point? â Be aware of authority granted â Assume malicious users as a design aid!
- 15. Stupid people Evil people Whatâs the difference? ï
- 16. Security-aware design âą "Authority" = what can you do at any point? â Be aware of authority granted â Assume malicious users as a design aid! âą Use POLA as a software design guideline â Forces intention-revealing interface â Minimizes surface area & reduces coupling
- 18. Typical API APIcallClient call I'm sorry, Dave, I'm afraid I can't do that
- 19. Rather than telling me what I can't do, why not tell me what I can do?
- 21. Client Service Login Available Capabilities Capability-based API Many available actions initially
- 22. Client Service Use a capability Available Capabilities Capability-based API Fewer available actions in a given state
- 24. Client TicTacToe Service Request Response Tic-Tac-Toe as a service Proper name is "Noughts and Crosses" btw TIL: "Butter, cheese and eggs" in Dutch
- 25. Tic-Tac-Toe API (obvious version) type TicTacToeRequest = { player: Player // X or O row: Row col: Column }
- 26. Tic-Tac-Toe API (obvious version) type TicTacToeResponse = | KeepPlaying | GameWon of Player | GameTied
- 28. What kind of errors can happen? âą A player can play an already played move âą A player can play twice in a row âą A player can forget to check the response and keep playing
- 29. Intention-revealing interface "If a developer must consider the implementation of a component in order to use it, the value of encapsulation is lost." -- Eric Evans, DDD book
- 30. âMake illegal operations unavailableâ Donât let me do a bad thing and then tell me off for doing it... Yes, you could return errors, but...
- 31. Client TicTacToe Service New Game Available Moves Tic-Tac-Toe service with capabilities Nine available moves
- 32. Client 1st move Available Moves Tic-Tac-Toe service with capabilities Eight available moves TicTacToe Service
- 33. Client Available Moves Tic-Tac-Toe service with capabilities 2nd move Seven available moves TicTacToe Service
- 34. Client Available Moves Tic-Tac-Toe service with capabilities 3rd move Six available moves, etc TicTacToe Service
- 35. Client No available Moves Tic-Tac-Toe service with capabilities Winning move TicTacToe Service
- 36. Tic-Tac-Toe API (cap-based version) type MoveCapability = unit -> TicTacToeResponse // aka Func<TicTacToeResponse> type TicTacToeResponse = | KeepPlaying of MoveCapability list | GameWon of Player | GameTied
- 37. Tic-Tac-Toe API (cap-based version) type MoveCapability = unit -> TicTacToeResponse // aka Func<TicTacToeResponse> type TicTacToeResponse = | KeepPlaying of MoveCapability list | GameWon of Player | GameTied
- 38. Tic-Tac-Toe API (cap-based version) type MoveCapability = unit -> TicTacToeResponse // aka Func<TicTacToeResponse> type TicTacToeResponse = | KeepPlaying of MoveCapability list | GameWon of Player | GameTied type InitialMoves = MoveCapability list Where did the "request" type go? Where's the authorization?
- 40. What kind of errors can happen? âą A player can play an already played move âą A player can play twice in a row âą A player can forget to check the response and keep playing Is this good security or good design? All fixed now! ï
- 41. HATEOAS Hypermedia As The Engine Of Application State âA REST client needs no prior knowledge about how to interact with any particular application or server beyond a generic understanding of hypermedia.â RESTful done right
- 42. How NOT to do HATEOAS POST /customers/ GET /customer/42 If you can guess the API youâre doing it wrong Security problem! Also, a design problem â too much coupling.
- 43. How to do HATEOAS POST /81f2300b618137d21d / GET /da3f93e69b98 You can only know what URIs to use by parsing the page Each of these URIs is a capability
- 44. Tic-Tac-Toe HATEOAS [ { "move": "Play (Left,Top)", "rel": "LeftTop", "href": "/move/ec03def5-7ea8-4ac3-baf7-b290582cd3f2" }, { "move": "Play (Left, Middle)", "rel": "Left Middle", "href": "/move/d4532ca0-4e61-4fae-bbb1-fc11d4e173df" }, { "move": "Play (Left, Bottom)", "rel": "Left Bottom", "href": "/move/fe1bfa98-e77b-4331-b99b-22850d35d39e" } ... ]
- 46. Good security => Good design Good design => Good security
- 47. DESIGN CONSEQUENCES OF USING CAPABILITIES Not just for APIs -- use these design techniques inside a bounded context too
- 48. Example: Read a customer from a database
- 49. Controller/ API Business Logic Database Client Could also be Onion architecture or Ports and Adapters -- not important
- 50. Controller/ API Business Logic Database Client Which component decides whether you are allowed to read the customer? But then any other path has complete access to the database ï
- 51. Controller/ API Business Logic Database Client But then it doesnât have enough context to decide ï Which component decides whether you are allowed to read the customer?
- 52. Controller/ API Business Logic Database Client Global Authorizer Are you doing this already? Which component decides whether you are allowed to read the customer?
- 53. Controller/ API Business Logic Database Client Dependency Injection Which component decides whether you are allowed to read the customer?
- 54. public class CustomerController : ApiController { readonly ICustomerDb _db; public CustomerController(ICustomerDb db) { _db = db; } [Route("customers/{customerId}")] [HttpGet] public IHttpActionResult Get(int customerId) { var custId = new CustomerId(customerId); var cust = _db.GetProfile(custId); var dto = DtoConverter.CustomerToDto(cust); return Ok(dto); }
- 55. public interface ICustomerDb { CustomerProfile GetProfile(CustomerId id); void UpdateProfile(CustomerId id, CustomerProfile cust); void CreateAccount(CustomerId id, CustomerProfile cust); void DeleteAccount(CustomerId id); void UpdateLoginEmail(CustomerId id, string email); void UpdatePassword(CustomerId id, string password); } How much authority do you really need?
- 56. public interface ICustomerDb { CustomerProfile GetProfile(CustomerId id); void UpdateProfile(CustomerId id, CustomerProfile cust); void CreateAccount(CustomerId id, CustomerProfile cust); void DeleteAccount(CustomerId id); void UpdateLoginEmail(CustomerId id, string email); void UpdatePassword(CustomerId id, string password); } How much authority do you really need?
- 57. public interface ICustomerDb { CustomerProfile GetProfile(CustomerId id); } How much authority do you really need?
- 58. Func<CustomerId,CustomerProfile> How much authority do you really need?
- 59. public class CustomerController : ApiController { Func<CustomerId,CustomerProfile> _readCust; public CustomerController(Func<..> readCust) { _readCust = readCust; } [Route("customers/{customerId}")] [HttpGet] public IHttpActionResult Get(int customerId) { var custId = new CustomerId(customerId); var cust = _readCust(custId); var dto = DtoConverter.CustomerToDto(cust); return Ok(dto); }
- 60. Controller /API Business Logic Database Use Case Controller /API Business Logic Database Use Case Controller /API Business Logic Database Use Case Global Authorizer Every controller is injected with minimal capabilities it needs (aka functions)
- 61. Controller /API Business Logic Database Use Case Controller /API Business Logic Database Use Case Controller /API Business Logic Database Use Case Global Authorizer Vertical slices Don't mention microservices
- 62. But wait, there's more!
- 63. public class CustomerController : ApiController { [Route("customers/{customerId}")] [HttpGet] public IHttpActionResult Get(int customerId) { var custId = new CustomerId(customerId); var readCust = authorizer.GetReadCustCap(custId); if (readCust != null) { var cust = readCust(); var dto = DtoConverter.CustomerToDto(cust); return Ok(dto); } else // return error }
- 64. TRANSFORMING CAPABILITIES FOR BUSINESS RULES
- 65. Capability transformer capability constrained capability Capabilities are functions... ...so can be transformed to implement business rules
- 69. How to revoke access in a cap-based system? It's hard to revoke physical keys in the real world... But this is software!
- 75. Reasons for access control âą Prevent any access at all. âą Limit access to some things only. âą Revoke access when you are no longer allowed. âą Grant and delegate access to some subset of things. Itâs not always about saying no!
- 79. Controller /API Business Logic Database Use Case Inject authority to read just one customer Global Authorizer Services (e.g. Read customer and send them email) Security risk & implicit dependency
- 80. Controller /API Business Logic Database Use Case Services (e.g. Read customer and send them email) Inject authority to read just one customer Global Authorizer
- 81. Delegation of capabilities Full authority (at start up) Parent Component Some capabilities Child Component transformer e.g. Only once Child Component Only during office hourstransformer Delegate capabilities Delegate capabilities
- 82. CONCLUSION
- 83. Common questions âą Is this overkill? Is it worth it? â It depends.... â Useful as a thought experiment âą How does this relate to DDD? â Intention-revealing interfaces â Map commands from event storming to capabilities
- 84. Common questions âą Are you saying that all external IO should be passed around as capabilities? â Yes!You should never access any ambient authority. â You should be doing this anyway for mocking. âą How do you pass these capabilities around? â Dependency injection or equivalent
- 85. Common questions âą Wonât there be too many parameters? â Less than you think! â Counter force to growth of interfaces â Encourages vertical slices (per use-case) âą Canât this be bypassed by reflection or other backdoors? â Yes. This is really all about design not about total security.
- 86. Summary âą Good security ï good design â Bonus: get a modular architecture! âą Use POLA as a design principle â Donât trust other people to do the right thing â Donât force other people to read the documentation! âą Intention revealing interfaces â Don't force the client to know the business rules â Make interfaces more dynamic â Change the available capabilities when context changes
- 87. Thanks! @ScottWlaschin fsharpforfunandprofit.com/cap Contact me Slides and video here F# consulting