<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 21, 2016 at 2:30 PM, Brian Bouterse <span dir="ltr"><<a href="mailto:bbouters@redhat.com" target="_blank">bbouters@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Thanks for the reply. A few questions inline.<span class=""><br>
<br>
On 09/20/2016 01:32 PM, Michael Hrivnak wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
Great questions.<br>
<br>
On Tue, Sep 20, 2016 at 12:49 PM, Brian Bouterse <<a href="mailto:bbouters@redhat.com" target="_blank">bbouters@redhat.com</a><br></span><span class="">
<mailto:<a href="mailto:bbouters@redhat.com" target="_blank">bbouters@redhat.com</a>>> wrote:<br>
<br>
<br>
    1. To recap what SSL users should transition onto... For a use case<br>
    where a user wants to place a file on a system and that system or a<br>
    user who can access that file can use that as their credential (like<br>
    SSL did for us) how will they do that? Is it that they would use<br>
    some cert based authn through apache or FreeIPA? Or would they get a<br>
    never expiring or long-expiring JWT that an admin generated at one<br>
    time and put in a file?<br>
<br>
<br>
Those users would start by obtaining a JWT. Then they would need to<br>
store it somewhere between requests. Continuing the current pattern of<br>
storing a file in ~/.pulp/ seems like a reasonable thing to do for a<br>
token. I imagine that's what we'd have pulp-admin do, but maybe someone<br>
will suggest a better idea.<br>
</span></blockquote>
+1 to putting a JWT in ~/.pulp/ as an auth option.<br>
<br>
Only Pulp can hand out JWT that are valid for Pulp since the server has the key right?</blockquote><div><br></div><div>Yes. Although if in the future we found it advantageous to offload this to a different service, we could.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Will our JWT have a timeout? If so can a user have an option to set how long the credential will be good for?</blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
    2. Say you have an apache system that is aware of two or more authn<br>
    authorities. How will a user 'foo' in each of them be told apart,<br>
    are they namespaced in some way?<br>
<br>
<br>
I don't think we would attempt to namespace them. Multiple authorities<br>
would be checked in a configured order, and the first one to allow<br>
authentication would win. If a deployer of pulp has multiple authorities<br>
with overlapping users, I think it's up to them to manage the priority<br>
of each authority. This approach would allow an organization to migrate<br>
from one authority to another without having to worry about updating<br>
prefixes or namespaces in pulp.<br>
</blockquote></span>
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.<br>
<br>
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.</blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div></div><br></div></div>