...
"First, because of the complexity, services must manage their own access control. Don't try to build a central service that says "yes" or "no" to a ton of requests for different services. That's a dark, dark road to go down. Instead, ensure that a request to a service contains the requisite information required to determine if it should be answered. This leads to ..
Second, try to have a uniform way to document and express the security requirements and responses for each service, ideally a uniform protocol so that you can debug the security interactions between two services that are not related. For example, always passing through the user ID and their group IDs in the request header. Whatever it takes.
Finally, keep separate services truly separate: don't have a central database that stores all of the permissions and is utilized by different services, or you'll be right back at my first point ... unless you're still at a point where a shared data store is scaling just fine for you, which brings me to ..."
I can't find the video right now, but there was also some discussion of the difficulty in testing a system once you get beyond a small handful of roles as most services will assume a certain uniform level of access (e.g. the Analytics API is going to assume that if you can access the student data for a course, that you're allowed to see the course content as well, and won't be built to gracefully degrade).
The service code should still express things in terms of permissions internally of course, but the mapping of roles to permissions should happen at the service level.
...