Wrox Programmer Forums

Need to download code?

View our list of code downloads.

| FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read
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 tens of thousands of software programmers and website developers including Wrox book authors and readers. As a guest, you can read any forum posting. By joining today you can post your own programming questions, respond to other developers’ questions, and eliminate the ads that are displayed to guests. Registration is fast, simple and absolutely free .
DRM-free e-books 300x50
Reply
 
Thread Tools Search this Thread Display Modes
  #1 (permalink)  
Old February 11th, 2016, 09:05 AM
Registered User
Points: 15, Level: 1
Points: 15, Level: 1 Points: 15, Level: 1 Points: 15, Level: 1
Activity: 0%
Activity: 0% Activity: 0% Activity: 0%
 
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..
Reply With Quote
  #2 (permalink)  
Old February 11th, 2016, 05:36 PM
Wrox Author
Points: 237, Level: 4
Points: 237, Level: 4 Points: 237, Level: 4 Points: 237, Level: 4
Activity: 0%
Activity: 0% Activity: 0% Activity: 0%
 
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
Reply With Quote
The Following User Says Thank You to nick_t For This Useful Post:
sherifsabry20000 (February 11th, 2016)
  #3 (permalink)  
Old February 11th, 2016, 07:32 PM
Registered User
Points: 15, Level: 1
Points: 15, Level: 1 Points: 15, Level: 1 Points: 15, Level: 1
Activity: 0%
Activity: 0% Activity: 0% Activity: 0%
 
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?
Reply With Quote
  #4 (permalink)  
Old February 12th, 2016, 04:18 PM
Wrox Author
Points: 237, Level: 4
Points: 237, Level: 4 Points: 237, Level: 4 Points: 237, Level: 4
Activity: 0%
Activity: 0% Activity: 0% Activity: 0%
 
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).
Reply With Quote
  #5 (permalink)  
Old February 12th, 2016, 05:24 PM
Registered User
Points: 15, Level: 1
Points: 15, Level: 1 Points: 15, Level: 1 Points: 15, Level: 1
Activity: 0%
Activity: 0% Activity: 0% Activity: 0%
 
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?
Reply With Quote
  #6 (permalink)  
Old February 13th, 2016, 06:59 AM
Wrox Author
Points: 237, Level: 4
Points: 237, Level: 4 Points: 237, Level: 4 Points: 237, Level: 4
Activity: 0%
Activity: 0% Activity: 0% Activity: 0%
 
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.
Reply With Quote
Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are Off


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



All times are GMT -4. The time now is 05:14 PM.


Powered by vBulletin®
Copyright ©2000 - 2019, Jelsoft Enterprises Ltd.
© 2013 John Wiley & Sons, Inc.