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

Pulp-dev mailing list

Reply via email to