What is the new service you're looking to develop?
I think the answer depends on your needs. Most openstack projects use
the oslo policy library as a PDP to protect API access . On the
other hand, if you want dynamic rules and very fine-grained access
control, you may also consider Openstack Congress  which offers a
general and flexible rule framework.
Either way, here is how it typically works in an openstack service:
Policy rules are written and stored in the chosen policy framework.
For oslo policy, this is typically the json file containing policy
rules. In Congress, the policy store is managed by Congress service
and accessed via Congress API.
When an API is accessed, the service serving the API acts as the PEP.
It consults the PDP to see whether something is allowed, and enforces
that decision. For oslo policy, this is a library call . For
Congress, this is an API call to Congress service to query the result
of rule evaluation .
For oslo policy, the main PAP is the json file containing the policy
rules. For congress, the policies and rules are managed through the
Hope that helps. Happy to talk further!
OpenStack Congress contributor
On Wed, Aug 15, 2018 at 8:29 AM, B.M.Canning <bmc20 at kent.ac.uk> wrote:
> Dear OpenStackers,
> Hello, I'm new to the list.
> I would like to know what support is available for creating a new
> OpenStack service that contains role-based access control components,
> such as a Policy Decision Point (PDP), inside the new service.
> I have come across oslo.policy in my research, is this what other OpenStack
> components use for their PEP, PDP, PAP and PIP? If so, what resources are
> available to help developers use this framework in their projects?
> As part of my MSc degree in computer science, I am conducting a research
> project into the application of self-adaptation in authorisation
> infrastructures as a means of mitigation against insider threats towards
> cloud computing infrastructures. I'm using Keystone as a role-based
> access control system to protect access to a web-based game, and actions
> that a player can perform in the game, which represents computing
> resources, here snakes and ladders. Cheating in the game represents the
> malicious behaviour of an insider threat, to which the authorisation
> infrastructure responds by reducing/removing the user's privileges. The
> intention is to have the game represent an OpenStack service, like
> Swift. I am currently using the Queens release of Keystone and v3 of the
> API for both service-level and infrastructure-level policy decisions.
> Best wishes,
> Bruno Canning
> School of Computing, University of Kent
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to : openstack at lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack