On Wed, Sep 21, 2016 at 2:30 PM, Brian Bouterse <bbout...@redhat.com> wrote:

> 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 <bbout...@redhat.com
>> <mailto:bbout...@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?


Yes. Although if in the future we found it advantageous to offload this to
a different service, we could.


>


> Will our JWT have a timeout? If so can a user have an option to set how
> long the credential will be good for?


Probably they should have an expiration. I'd be inclined to start with a
configurable token lifetime that's global (similar to what we have now with
ssl certs), and later add the ability for users to specify their own if
that's valuable. I'm not sure how valuable that would be though.


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


It would be good to hear from users with a multi-authority scenario (I
suspect it's somewhat rare). This is getting pretty far outside what should
be pulp's core competencies, but we should definitely know enough to cover
our bases. For the most part, I think these authorities tend to have some
concept of a realm. There may be a scenario where there are two distinct
authorities, each with their own realm, perhaps as the result of two
companies merging. If users are created in pulp with their realm in the
username (email address style), and multiple authorities are configured,
that should work out and be a reasonable use case. When it comes to
configuring sssd and mod_lookup_identity to actually do that, we'd probably
need to consult someone with expertise.

I think aiming to support one external authority for starters is a fine
approach, and we can seek expert guidance as necessary from our IdM friends
on working with multiple external authorities.
_______________________________________________
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Reply via email to