| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Allows for a new form of document signature.
pkiz_sign will take data and encode it in a string that starts with
the substring "PKIZ_". This prefix indicates that the data has been:
1) Signed via PKI in Crypto Message Syntax (CMS) in binary (DER) format
2) Compressed using zlib (comparable to gzip)
3) urlsafe-base64 decoded
This process is reversed to validate the data.
middleware/auth_token.py will be capable of validating Keystone
tokens that are marshalled in the new format. The current existing
"PKI" tokens will continue to be identified with "MII", issued by
default, and validated as well. It will require corresponding changes
on the Keystone server to issue the new token format.
A separate script for generating the sample
data used in the unit tests,
examples/pki/gen_cmsz.py,
also serves as an example of how to
call the API from Python code.
Some of the sample data for the old tests had to be regenerated. A
stray comma in one of the JSON files made for non-parsing JSON.
Blueprint: compress-tokens
Closes-Bug: #1255321
Change-Id: Ia9a66ba3742da0bcd58c4c096b28cc8a66ad6569
|
| |
|
|
|
|
|
|
|
|
| |
This token is used for auth_token testing and is a valid v3 token other
than the catalog which is in v2 format.
Convert the catalog to V3 format. Whilst there pretty print the token so
we can more easily see what's happening.
Change-Id: I893ea6e76f3fcc20b13b331911d7b8288b98991d
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Splits the file that generates the sample data into two.
One part is the set of individual functions. The second
is a script that calls each of the functions in turn. By
splitting them, it becomes easier to regenerate just a subset
of the sample data. The use-case that prompted this change
was the need to regenerate the signed tokens based on a different
algorithm. Without this change, all of thecertificates would
need to be regenerated, and that has nothing to do with the
actual change required.
Change-Id: I53b6cfde98a52f0a59b06ad8abbe0d2f1251f796
|
| |/
|
|
|
|
|
|
| |
methods is a required field of v3 tokens but none of the sample tokens
have them. This field is required for determining the difference between
a v2 and a v3 AccessInfo object.
Change-Id: I4d45e90f24eeb2f35451549771ad999628619c20
|
| |
|
|
|
|
|
|
|
|
| |
Some files still use trademark OpenStack LLC in header, which
should be changed to OpenStack Foundation.
NOTE: tools/install_venv.py is not touched, should sync with oslo
Change-Id: I01d4f6b64cf1a152c4e190407799ce7d53de845f
Fixes-Bug: #1214176
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This timestamp is the last possible moment that can be represented on
32-bit systems as an integer.
As a consequence of revising the JSON examples, the corresponding PEM
files must be re-generated as well.
Change-Id: Ic6014c08b4545db036605beef1e6a8829ed347c4
Related-Bug: 1190054
Related-Bug: 1225084
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Extend RSA keylength to 2048 bits by default,
as the previous default of 1024 bit is considered
weak since 12/31/2010.
Also unify the message_md to the openssl builtin
default.
Fixes bug 1103002
Change-Id: I619fc32b62beab4458ee6f21bf8dc7499fe400d7
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Explicitly checks the expiry on the tokens, and rejects tokens that
have expired
had to regenerate the sample data for the tokens as they all had been
generated with values that are now expired.
bug 1179615
Change-Id: Ie06500d446f55fd0ad67ea540c92d8cfc57483f4
|
| |
|
|
|
|
| |
- Regenerate tokens to change expires in expires_at.
Change-Id: Iaa62dca50d34a228e4850b59d263b807c5ee3549
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now that the Identity server supports v3 tokens, the auth_token
middleware should permit the in-line validation of such a token. This
essentially means just setting any new environment items
that correspond to the new attributes that may be in a v3 token (such
as domains), as well as allowing for the slight format differences.
Most of the work in this change is actually in the unit tests, where
it was important to try and enable the existing tests to be run against
an auth_token middleware configured for both v2 and v3. This meant
restructing the test class so that the token format is separated
from the individual tests and is initialized by the class Setup().
Since there are some new signed token formats included in this testing,
a new set of the signed tokens was generated.
Fixes Bug #1132390
Change-Id: I78b232d30f5310c39089fbbc8e56c23df291f89f
|
|
|
This step in the process duplicates the auth-token code to keystoneclient but,
for the moment, leaves a copy in its origional location in keystone.
Testing for auth-token is also copied across, as is the cms support file.
Although no other project will yet pick up the code here in the client, since
the paste.ini files haev not yet been updated, it would work if anyone
did reference it.
Once the client code is in, the next step is to update all the other
project paste files, and then finally retire the code from keystone.
Change-Id: I88853a373d406020d54b61cba5a5e887380e3b3e
|
