OpenAM.
http://forgerock.com/openam.html
How should user details and access rights be stored? (data model, location, format)
Identity Manager. Separate from any web server. LDAP-based.
What are good design patterns for representing and tracking these in the server? (sessions in memory, db lookups each time, etc)
Solved by your framework. Think no more. Just use your framework's already-built good design patterns.
What are good patterns for mapping these rights to the services in a secure way in the code base?
Solved by your framework. Each framework uses a slightly different approach. Each language has slightly different features. Django, for example, uses Python's decorators heavily for this.
What architectural choices can help keep the system more secure and reliable?
More? More than what?
If your different bounded contexts understand the meaning/purpose of a country differently, then you need to model it appropriately different in each one. However, if we are speaking simply of reference data of ISO codes and names, then I believe it's pretty fair and standard to stash it wherever is convenient and make it accessible to all interested parties. For example: a database, a configuration file, a web service, etc.
I also wanted to look at your model a little bit. The pieces you have listed could very well be "entities" in one "bounded context", depending on the company's structure. BCs often end up being defined around different areas/departments/teams, since that's frequently the natural boundary between "ubiquitous language"s. So for example, instead of Sales/Products/Orders I'd expect the BCs to be along the lines of Sales/Manufacturing/Warehousing.
Inside those BCs, you don't focus on the nouns. You focus on the use cases, and create models of the nouns that can fulfill the use cases. The methods on an "aggregate root" execute use cases and make the appropriate changes to the related models.
... all models are wrong, but some are useful.
Also bear in mind that each BC may use an entirely different system or architecture. A given BC may not merit using "DDD software components" at all, and most of them probably don't. DDD is less about prescriptive software components and more about the process of designing software. The point is to focus on understanding the company's bounded contexts, mapping out each context's ubiquitous languages, and modeling the code for that context using their ubiquitous language. That way when you interact with stake holders and refer to the code, it sounds to them like you are speaking in business terms they understand. And recognizing that the same word has different meanings in different BCs.
There are specific patterns brought forth by DDD (e.g. repository, specific layering, etc.) that are means to an end. But these patterns are not guaranteed to be the best patterns for every case, even within DDD. Just like DDD is not "the" answer for every project. You just have to do what your analysis suggests is the most practical thing to do.
Best Answer
Apart from what Alexander Langer said, there are not only good reasons for, but actual security policies for going even further and don't even hold any kind of credentials or temporary tokens in your domain logic.
Practically speaking (and I apologise for not knowing DDD or the exact case well):
To imagine the potential implications of a security decision of this kind, consider the fact, that an "information" stored in a token/credential/user-id is not just the binary content of the data, but everything reachable from this data using today's or future possibilities (cracking the hashes, crawling the othe parts of the system using the token by an attacker etc.)