[Pulp-dev] authentication proposal for 3.0

[Michael Hrivnak]

Great questions.

On Tue, Sep 20, 2016 at 12:49 PM, Brian Bouterse <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.


> 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.


>
> 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.


>
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20160920/4979cf6f/attachment.htm>