Without this patch, bootstrap emits deprecation warnings in the tests
about opting into immutable roles. This change follows the warnings'
advice so that the warnings no longer clutter up the log output.
Change-Id: I72acef2409acc5efad84390cd7f63683a9842a5a
Adds a new model and provider for receipts which are
very similar to tokens (fernet based), and share the
same fernet mechanisms.
Adds changes to the auth layer to handle the creation,
validation, and consumptions of receipts as part of
the auth process.
Change-Id: Iccb6e6fc7aee57c58a53f90c1d671402b8efcdbb
bp: mfa-auth-receipt
This change adds tests cases for the default roles keystone
supports at install time. It also modifies the policies for the
credentials API to be more self-service by properly checking
for various scopes.
Closes-Bug: 1788415
Partial-Bug: 968696
Change-Id: Ifedb7798c96930b6cc0f91159a14a21ac4b02f9f
The unit test uses sqlite for test which closes db foreign keys
function by default. This patch enabled the sqlite foreign keys
function for unit test by default.
The "project" table is a self referencing FK table(id <-> domain_id
column). So when the FK is enabled, there must exists a root record
before insert data to this table. It's <<keystone.domain.root>>.
Usually, the <<keystone.domain.root>> recored is inserted into the
table once operators run "keystone-manage db_sync" command when
deploy Keystone. But the unit test code doesn't run this command,
it initialise the db schema by reading sqlalchemy object model, so
the <<keystone.domain.root>> record is missed. Then we can't create
any project record, it'll raise FK error.
So in this patch, before creating any projects in the test, we must
ensure the <<keystone.domain.root>> record exists first.
Change-Id: I565d12395ca39a58ba90faf8641a9e02d986aeb9
Closes-Bug: #1744195
Our previous token model (``KeystoneToken``) was built to accept
complete token responses and use reflection to be more pythonic. Now
that we're no longer supporting token providers or storage layers
that rely on passing around full token responses, we can introduce
a more pythonic way of building tokens.
This commit introduces a new TokenModel object that is intended to be
used with composition, starting with a blank state and allowing parts
of the application to fill in the blanks. This should hopefully make
our entire authentication and validation API paths more clear and
understandable.
The following are a few benefits of adopting the new model.
First, this helps us simplify the interface between the token provider
API and the actual token providers. The token providers shouldn't have
to understand the API contract in order to work. Likewise, if we add
another API version, we shouldn't need to change multiple token
providers to ensure the API contract isn't violated depending on which
one is being used.
Second, this forces us to translate the token model into a token
response in a single place (e.g. the controller), isolating where we
represent API contracts. The is mostly an extension of the first
point, but it helps us be explicit in what we build and give to a
user. This type of architecture should help us avoid letting bugs like
bug 1763510 slip through our fingers.
Third, and somewhat subjectively, this makes the code easier to read
by dealing with objects in pythonic ways as opposed to understanding
large data structures in the controller, manager, and driver layers of
a subsystem.
Partial-Bug: 1778945
Change-Id: I2e461e7fdf4f47547e07fc279ec4e6fbd86f23ad
jneo8