[Pulp-list] Auth Issues

[Jason Dobies]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jeff and I ended up digging pretty deep into our auth subsystem and came
up with a bunch of issues. I'm thinking next sprint we should take some
time to revamp our auth handling to clean this up.

- - The two CLIs improperly use each other's certificates. Currently, both
utilize the same preference scheme for determining the type of auth to
use (username/pass, admin cert, consumer cert). This leads to some wonky
situations where a machine with both a consumer and admin cert will use
the admin cert for consumer operations, which leads to (among other
things) incorrect reporting of who initiated the action.

The desired behavior should be based on which CLI is being invoked:
* pulp-admin: if a username/password are specified to the executable,
use those; otherwise, use an admin certificate if one exists.
* pulp-client: all commands require a consumer certificate except for
consumer create; username/password should be moved from being an
executable-level option to specific only to consumer create. In other
words, you use a username/password to get the consumer cert, but then
the consumer cert is the only way to do consumer operations from
pulp-client from there on.

- - The role checking lines between admin (read: user) and consumer are
blurred. Currently, we try to log you in as an admin. If we cannot, we
try to log you in as a consumer. I know we're reusing the same APIs for
both admin and consumer operations (in other words, if a consumer is
binding itself or an admin is binding a consumer, we use the same call),
but this just feels wrong. It allows the bug we face today, that admin
credentials are used for consumer initiated operations. The two
concepts, users v. consumers, are apples and oranges, but we don't
reflect that properly.

I haven't looked yet, but I doubt our API docs properly reflect this as
well. The consumer ID is required in all cases of the API, but I don't
think we document the auth requirements to make the call (those
requirements read something like "You either need to have the consumer
cert of the consumer with the same ID as the call edits OR you need to
have admin credentials"... and this is all before we have anything
role-related in place, which further complicates this).

- - Any consumer can edit another consumer. Our consumer verification
ensures that the consumer ID in your certificate is a valid consumer,
but doesn't actually check to make sure it's the consumer the API call
is acting on. Big security hole here.

- - The principal handling (auth.py) has a few issues:
- -- It is only set for admin users; the principal is left at the default
when a consumer initiated (pulp-client) command is run.
- -- The SystemPrincipal implementation is wonky. It's not a subclass of
User, yet is meant to be treated as one. What this leads to is checking
elsewhere in the code where you get the principal but then have to
determine if it's an actual user before being able to access data on it.
- -- The principal is not reset on each call to role check, which means if
a thread with a principal is set and tossed back into the pool, the next
call that uses that thread again is by default logged in.

- - All certificates, both admin and consumer, are generated with the same
serial number. This prevents us from ever implementing a certificate
revocation list (I just filed a bug on this this morning).



- -- 
Jason Dobies
RHCE# 805008743336126
Freenode: jdob
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJM4XVzAAoJEOMmcTqOSQHC2NUH/RvICKahbCJ5fatdX0nbqKFf
2l2XD2qlqJTofEumGE9yNQ7O1SzwndKbRcWjXc8JJlfmPLElmyjlQuU/zCiWuSSr
sIOhpqD73mgzm8iT4oMmWUUmHKI0uOQ6SwaoZZbYA5M/UnJZoPfEkrwOVbOKeW/C
XrMRYccFisF5PG7hCbK/W4WYobvpgo4u2Q68BTJMPBNsgiFPf89E5/+A6SpEgpy1
4CebQ4D6NTEtG3b64quVdZ5UZ4lvSUAdLmBZajtMmgRj2QtMYn2qFzkMvezI3Y+T
7ssFuzc/Y9og6tHRkfC0Y/IeNgX4lkAaMDQj2oMtCkOpoaQ/fvydC120q8BJQdg=
=Ke5n
-----END PGP SIGNATURE-----