Wrox Programmer Forums
|
BOOK: Patterns, Principles and Practices of Domain-Driven Design
This is the forum to discuss the Wrox book Patterns, Principles and Practices of Domain-Driven Design by Scott Millett; ISBN: 978-1-118-71470-6
Welcome to the p2p.wrox.com Forums.

You are currently viewing the BOOK: Patterns, Principles and Practices of Domain-Driven Design section of the Wrox Programmer to Programmer discussions. This is a community of software programmers and website developers including Wrox book authors and readers. New member registration was closed in 2019. New posts were shut off and the site was archived into this static format as of October 1, 2020. If you require technical support for a Wrox book please contact http://hub.wiley.com
 
Old February 11th, 2016, 09:05 AM
Registered User
 
Join Date: Feb 2016
Posts: 4
Thanks: 1
Thanked 0 Times in 0 Posts
Default Authentication & Authorization

Hi,

What's your take on authentication and authorization from a DDD point of view?

My initial understanding according to how bounded contexts should be constructed I would argue that there should be a separate BC for "Identity & Access". However, how do you share this data between the different BCs out there that are hosted on different servers?

As a concrete example, Let's say I'm building an AngularJS application for the profile page on Facebook using a composite UI built by aggregating the data in the browser using separate Ajax calls for each fragment.

My profile photo is retrieved from MediaBC. My personal info is retrieved from UserDetailsBC and my friend list is retrieved from the FriendBC. The actual profile page layout is hosted in the ProfileBC and will be managed by a web team as you suggested in one of the chapters.

Now what should be the workflow to authenticate the user and authorize each request sent to each BC? What's your technology recommendations for the process?

Last edited by sherifsabry20000; February 11th, 2016 at 06:52 PM..
 
Old February 11th, 2016, 05:36 PM
Wrox Author
 
Join Date: May 2015
Posts: 59
Thanks: 1
Thanked 5 Times in 5 Posts
Default

Hello,

Firstly, sorry for the delay. I stopped receiving notifications when there were new messages in the forum.

The tempting option is always to create an authentication web service. You store all the user credentials in one place and perform an RPC HTTP request to validate the user's credentials. So each of your three contexts might do this.

Alternatively, your users could log into this api directly which provides them with a session token. This session token could be stored in a distributed cache which each of your three BCs can query to validate the users token on each request.

Again though, you've got RPC calls and a single point of failure for all three services.

Another way to look at this scenario is to actually consider your service boundaries. Are those really three bounded contexts or could they live within a single bounded context and share a database? Did you arbitrarily determine those boundaries, or do they exist in the problem domain? Do they have their own linguistic nuances, or do they represent distinct business capabilities?

If your services boundaries are correct, and you'd rather not have fragile RPC calls in your workflow, then there are asynchronous approaches. One approach suggested by Udi Dahan almost 10 years ago is to load the entire set of usernames/passwords into memory inside each BC http://udidahan.com/2007/11/10/async...for-web-farms/

You could modify Udi's approach so that each bounded context uses its own private distributed cache to store the credentials. That way if you've got 10 instances of your API, or you have a number of smaller services in a BC, they don't all have to pull in the data. Remember, it's generally ok to share a database or cache within a bounded context.

Hope this helps but please continue to ask away if you have further questions.

Nick
The Following User Says Thank You to nick_t For This Useful Post:
sherifsabry20000 (February 11th, 2016)
 
Old February 11th, 2016, 07:32 PM
Registered User
 
Join Date: Feb 2016
Posts: 4
Thanks: 1
Thanked 0 Times in 0 Posts
Default

Thanks Nick for the reply :) I really like how you present several options and list the trade-off.

About this part:
Quote:
Originally Posted by nick_t View Post

Alternatively, your users could log into this api directly which provides them with a session token. This session token could be stored in a distributed cache which each of your three BCs can query to validate the users token on each request.

Again though, you've got RPC calls and a single point of failure for all three services.
I'm assuming by distributed cache you mean something similar to memcached, right?

I haven't used a distributed cache before, so I'm not sure how this becomes a single point of failure. How is that different from storing a local copy/cache of the full username and password list?
 
Old February 12th, 2016, 04:18 PM
Wrox Author
 
Join Date: May 2015
Posts: 59
Thanks: 1
Thanked 5 Times in 5 Posts
Default

Yes, traditionally memcached has been the preferred choice although I think Redis is very popular now.

I was trying to imply that if you have a single distributed cache that all of your bounded contexts are coupled to, a failure of that cache could bring down your entire system.

This differs to storing a local copy, because by storing a local copy, each bounded context will not be affected if another context or shared resource goes down.

The other scenario is that each bounded context has it's own distributed cache. Effectively, that's still storing it locally (within the bounded context).
 
Old February 12th, 2016, 05:24 PM
Registered User
 
Join Date: Feb 2016
Posts: 4
Thanks: 1
Thanked 0 Times in 0 Posts
Default

aah I see your point now and I totally agree with you.

My second part of the questions was about authorization. Normally each action in each bounded context should be checked to see if the user has enough permissions.

I've read mixed opinions about that. Some people prefer to have a centralized BC where all permissions are stored (Identity & Access as I mentioned in the first post) and others believe that each BC should be responsible for its own rules as it doesn't make sense outside of it.

Sense authorization is a cross cutting concern I'm not sure which side makes more sense. Do you think the case for authentication applies to authorization also?
 
Old February 13th, 2016, 06:59 AM
Wrox Author
 
Join Date: May 2015
Posts: 59
Thanks: 1
Thanked 5 Times in 5 Posts
Default

It's hard to be too specific without an example, but in general I would look for a solution that gives each team and bounded context the most autonomy, and avoids the need for collaboration or dependencies between teams.





Similar Threads
Thread Thread Starter Forum Replies Last Post
Authentication and Authorization Using AD and SQL GailCG ASP.NET 2.0 Basics 0 November 25th, 2008 11:29 AM
Window & Form authentication for Webparts ayyub123 ASP.NET 2.0 Basics 0 May 29th, 2007 09:58 AM
Form authentication & multiple login pages duydp ASP.NET 1.0 and 1.1 Professional 2 September 14th, 2004 12:18 PM





Powered by vBulletin®
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.
Copyright (c) 2020 John Wiley & Sons, Inc.