<div dir="ltr">Great questions.<br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 20, 2016 at 12:49 PM, Brian Bouterse <span dir="ltr"><<a href="mailto:bbouters@redhat.com" target="_blank">bbouters@redhat.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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?<br></blockquote><div> </div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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?</blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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.<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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.<br></blockquote><div><br></div><div>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.  </div></div></div></div>