[Pulp-dev] authentication proposal for 3.0
bbouters at redhat.com
Wed Sep 21 18:30:04 UTC 2016
Thanks for the reply. A few questions inline.
On 09/20/2016 01:32 PM, Michael Hrivnak wrote:
> Great questions.
> On Tue, Sep 20, 2016 at 12:49 PM, Brian Bouterse <bbouters at redhat.com
> <mailto:bbouters at redhat.com>> wrote:
> 1. To recap what SSL users should transition onto... For a use case
> where a user wants to place a file on a system and that system or a
> user who can access that file can use that as their credential (like
> SSL did for us) how will they do that? Is it that they would use
> some cert based authn through apache or FreeIPA? Or would they get a
> never expiring or long-expiring JWT that an admin generated at one
> time and put in a file?
> Those users would start by obtaining a JWT. Then they would need to
> store it somewhere between requests. Continuing the current pattern of
> storing a file in ~/.pulp/ seems like a reasonable thing to do for a
> token. I imagine that's what we'd have pulp-admin do, but maybe someone
> will suggest a better idea.
+1 to putting a JWT in ~/.pulp/ as an auth option.
Only Pulp can hand out JWT that are valid for Pulp since the server has
the key right?
Will our JWT have a timeout? If so can a user have an option to set how
long the credential will be good for?
> 2. Say you have an apache system that is aware of two or more authn
> authorities. How will a user 'foo' in each of them be told apart,
> are they namespaced in some way?
> I don't think we would attempt to namespace them. Multiple authorities
> would be checked in a configured order, and the first one to allow
> authentication would win. If a deployer of pulp has multiple authorities
> with overlapping users, I think it's up to them to manage the priority
> of each authority. This approach would allow an organization to migrate
> from one authority to another without having to worry about updating
> prefixes or namespaces in pulp.
Not namespacing them is fine, but then we are only supporting one authn
at a time except in the case where every user in authn A is the same
user in authn B. Otherwise this would be a security problem because pulp
can't tell user 'foo' in one authn from another so user 'foo' in one
authn can impersonate user 'foo' in the other.
The migration use case you describe is the one place where having 2
authn would be useful and safe because ^ is true. Other than that it is
only safe to have 1 authn configured. Am I thinking about this right?
I'm OK with only supporting one authn at a time with the launch of pulp 3.
> 3. Is the group use case compelling/important enough that it should
> be included with 3.0.0? We could avoid extending
> djangorestframework-jwt, to trust the REMOTE_USER_* variables which
> would lower the complexity of this area of pulp 3. I suspect the
> answer is yes, but I wanted to ask the question.
> I agree that auto-creation of users and groups is a feature that could
> easily wait for 3.1+. In the spirit of starting from a minimum viable
> product, I think we should do just the essentials until we at least have
> a working alpha of 3.0. Then we can prioritize additional work. From
> that point, we'll probably want to focus our 3.0 work on making
> backwards-incompatible changes while we have the chance.
+1 to waiting on this in favor of a Pulp MVP
> 4. If we are going to extend djangorestframework-jwt is the plan to
> contribute these new views upstream to them? It seems like
> djangorestframework-jwt would benefit integration with
> mod_lookup_identity. We could carry the implementation until they
> accepted it so we are not blocked.
> Heck ya! As much of this as we can do in that project, we should. I'm
> not sure if having a custom user model might make it more complicated to
> do this generically, but we'll certainly try.
More information about the Pulp-dev