The unicode() built-in does not exist under Python 3 so use
six.text_type, which is set correctly to str or unicode, instead.
Change-Id: Ieb29486c99400b4a10ce642cb3adc83f5e4420f6
Previously, Swift3 used client-facing HTTP headers to pass the S3 access
key, signature, and normalized request through the WSGI pipeline.
However, swauth did not validate that Swift3 actually set the headers;
as a result, an attacker who has captured a single valid request through
the S3 API may impersonate the user that issued the request indefinitely
through the Swift API.
Now, the S3 authentication information will be taken from a separate,
client-inaccessible namespace in the WSGI environment as defined in the
related change.
UpgradeImpact
This addresses a breaking API change in Swift3. No currently deployed
version of Swift3 will work with this. When upgrading swauth, operators
will need to upgrade Swift3 as well.
Change-Id: Ie5481a316397f46734e9dd0e77a8a87197ceec16
Related-Change: Ia3fbb4938f0daa8845cba4137a01cc43bc1a713c
Swauth uses token value as object name. Object names are logged in proxy
and object servers. Anybody with access to proxy/object server logs can
see token values. Attacker can use this token to access user's data in
Swift store. Instead of token, hashed token (with HASH_PATH_PREFIX and
HASH_PATH_SUFFIX) is used as object name now.
WARNING: In deployments without memcached this patch logs out all users
because tokens became invalid.
CVE-2017-16613
SecurityImpact
Closes-Bug: #1655781
Change-Id: I0d01e8e95400c82ef25f98e2d269532e83233c2c
Amazon S3 compatibility:
Due to security concerns raised, this change makes S3 support tunable
using a config option and is turned off by default.
Change-Id: I077f78946983f5d6b3b725dd6aa3ed178dc5604e
Signed-off-by: Prashanth Pai <ppai@redhat.com>
Currently, the input to HMAC function is the entire stored credential
in the format '<salt>$<hash>` but it should rather be only the hashed
key/password.
With this change, validate_creds() method is invoked and only the hash
of the password is used in HMAC computation.
Change-Id: I1a9bbcac6f49c23f3256572f148e55249a59f7ed
Signed-off-by: Prashanth Pai <ppai@redhat.com>
Older versions of swauth supported manually setting up a salt string in
conf file. This change re-introduces it and makes it a tunable option.
The current behavior of randomly generating salt for every password is
NOT affected with this change.
Change-Id: Ifdf6f806b954e4d41c083eeffa981cd7d0dd50b9
Signed-off-by: Prashanth Pai <ppai@redhat.com>
Problem:
If an existing swauth deployment changes `auth_type` in conf file to a
different one (for example: sha1 to sha512), all attempts to authorize
existing/old users will fail because of change in encoder type.
Fix:
With this change, the credentials match is done using an encoder with
which the password was initially encoded. This allows swauth deployments
to change auth_type and old users will still be able to authorize.
Closes-Bug: 1516980
Change-Id: I8a5c397d0796062f4109c59b6dc61b14d4a97e4b
Signed-off-by: Prashanth Pai <ppai@redhat.com>
This issue can be hit when swift3 middleware is in the pipeline.
Change-Id: If87a6663efcf31febe4a207b3d7f331b5f79b834
Signed-off-by: Prashanth Pai <ppai@redhat.com>
E127 continuation line over-indented for visual indent
E131 continuation line unaligned for hanging indent
Change-Id: I19ceb58d8545fb1b585e04b40418271f6ff56a5e
Currently, in cases where swauth returns a JSON document as its body,
it does not specify a content type, and swob defaults it to text/html.
This change uses a standard content type of 'application/json' in each
of these instances, and adjusts the tests accordingly.
Closes-Bug: #1545430
APIImpact
Change-Id: I96d343a87f462811bcefb7d402887f8a570fe6bd
Use pbr for versioning when developing but use
PKG-INFO file in production. This lets you build
swauth package that don't require pbr to be installed
at all. You would need pbr on machine building package
but not on machines that install the package.
Stolen from Swift:
https://github.com/openstack/swift/blob/master/swift/__init__.py
Change-Id: Ic3a8fe1d9fe8d7d1f84b63142049970295fbcaab
According to https://github.com/gholt/swauth/issues/73 nobody
knows why is this here. Let's try to remove it :).
Change-Id: I6de2c7eca5b7c4cbed61c966149055705efe8323
When you try to create account with same suffix as already existed
before, Swift raises error. But SwAuth already created container for
this account in .auth which creates inconsistency.
Changed the code to only allow the super_admin to delete a reseller_admin.
This follows the same logic of user creation, where only the super_admin
can create a reseller_admin.
Also, took the opportunity to refactor some code and implemented
get_user_detail method to remove duplicated code
Signed-off-by: Thiago da Silva <thiago@redhat.com>
Users were not able to update their own password/key
with the update operation resulting in 403 (HTTPForbidden).
EXAMPLES:
Command to update password/key of regular user:
gswauth-add-user -U account1:user1 -K old_pass account1 user1 new_pass
Command to update password/key of account admin:
gswauth-add-user -U account1:admin -K old_pass -a account1 admin new_pass
Command to update password/key of reseller_admin:
gswauth-add-user -U account1:radmin -K old_pass -r account1 radmin new_pass
Signed-off-by: Prashanth Pai <ppai@redhat.com>
* New conf value of max_token_life, existing token_life conf value is
now just the default token life.
* When a user requests a token, they can send an
X-Auth-Token-Lifetime header with the number of seconds they'd like
the token to be valid for. This will be capped to max_token_life.
* Response to getting a token has new X-Auth-Token-Expires header
that is the number of seconds the token is valid for.
Ondřej Nový