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?

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

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

About this part:
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?

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).

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?

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.