Re: [Pulp-dev] authentication proposal for 3.0

[Michael Hrivnak]

On Wed, Sep 21, 2016 at 2:30 PM, Brian Bouterse  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 > > 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

Re: [Pulp-dev] authentication proposal for 3.0

[Brian Bouterse]

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


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
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] authentication proposal for 3.0

[Michael Hrivnak]

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.


> 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.
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] authentication proposal for 3.0

[Brian Bouterse]

This plan looks really great. Thank you both for getting this effort going!

I have a couple of questions/ideas. If you want these on the ticket 
instead just let me know.


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?


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?


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.


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.


Thanks again for this great plan. It includes so many good, well thought 
out ideas and decisions.


-Brian


On 09/20/2016 10:47 AM, Michael Hrivnak wrote:


Tanya and I have been evaluating authentication use cases against
available solutions for Pulp 3. This email includes a summary of the
goals we identified, based input from numerous stakeholders, and a
working proposal for a set of technologies we can use to achieve them.
Please provide feedback, ask questions, and suggest alternatives if you
know of something that may be better. I hope to turn this thread into a
set of redmine tasks and stories soon.

Please note that this covers authentication only. Authorization is a
related, but distinct, problem that we think can be solved separately.

Planning thus far has been tracked here:

https://pulp.plan.io/issues/2090

Goals
-

- As a user, I can authenticate to the REST API when pulp is the authn
authority.
- As a user, I can authenticate to the REST API using an external
authority such as FreeIPA or AD.
- Participate in the django auth ecosystem so we don't have to reinvent
things, and so we can integrate well with django add-ons.
- The REST API does not and should not have sessions. Any persistent
token should be used for auth only.
- Authenticating to external authorities is hard. To the extent that
it's reasonable to do so, leverage other tools for this.

TL;DR


The working proposal is to use djangorestframework-jwt for token-based
authentication to the REST API, and leverage a set of apache modules to
handle authentication and retrieval of user attributes from an external
authority.

Status Quo


Pulp 2 supports client SSL certificates as an option for authentication,
and as the only option when using the "login" feature. Client SSL certs
are a well-known and tested standard that is robust. However, their
complexity has caused continued friction in the user experience.
Situations such as an expired certificate, changing the CA on the
server, or restricted filesystem access to a certificate are difficult
to diagnose in large part because SSL libraries do a poor job of error
reporting. Connection negotiation fails, and it can be unclear why.

From a development perspective, working with client ssl certificates can
be challenging, such as the requirement from many libraries to provide a
path to a certificate on disk.

As such, while client SSL certificates would be a viable solution for
pulp 3, a token-based authentication approach would be simpler and more
in-line with how other APIs handle authentication.

Token authentication may be marginally less secure than client SSL
certificates, since the entire token must be sent with every request.
However, in order for that to be compromised (assuming https is in use),
a third party would need the ability to eavesdrop and decrypt the ssl
traffic.

Basic Auth


Django and DRF (django rest framework) provide basic auth support out of
the box, including password management. This can be enabled for the
entire REST API and any other views we want.

Tokens
--

Most modern network-based APIs use some variety of token authentication.
A token is a string obtained after proving identity (through basic auth
or some other means), which is used to prove identity for future
requests by including it in an Authorization header.

Authenticating against an external authority can be an expensive
operation, particularly in terms of latency and load on the external
service. Using tokens allows the external authn to take place only once
per user within some period of time

Re: [Pulp-dev] authentication proposal for 3.0

[Kodiak Firesmith]

As an AD/SSSD user (mod_auth_gssapi); I like where this is going.  Thank
you for proposing a path that continues to use Apache REMOTE_USER, and we
very much look forward to being able to use AD groups and auto-creation.

 - Kodiak
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

[Pulp-dev] authentication proposal for 3.0

[Michael Hrivnak]

Tanya and I have been evaluating authentication use cases against available
solutions for Pulp 3. This email includes a summary of the goals we
identified, based input from numerous stakeholders, and a working proposal
for a set of technologies we can use to achieve them. Please provide
feedback, ask questions, and suggest alternatives if you know of something
that may be better. I hope to turn this thread into a set of redmine tasks
and stories soon.

Please note that this covers authentication only. Authorization is a
related, but distinct, problem that we think can be solved separately.

Planning thus far has been tracked here:

https://pulp.plan.io/issues/2090

Goals
-

- As a user, I can authenticate to the REST API when pulp is the authn
authority.
- As a user, I can authenticate to the REST API using an external authority
such as FreeIPA or AD.
- Participate in the django auth ecosystem so we don't have to reinvent
things, and so we can integrate well with django add-ons.
- The REST API does not and should not have sessions. Any persistent token
should be used for auth only.
- Authenticating to external authorities is hard. To the extent that it's
reasonable to do so, leverage other tools for this.

TL;DR


The working proposal is to use djangorestframework-jwt for token-based
authentication to the REST API, and leverage a set of apache modules to
handle authentication and retrieval of user attributes from an external
authority.

Status Quo


Pulp 2 supports client SSL certificates as an option for authentication,
and as the only option when using the "login" feature. Client SSL certs are
a well-known and tested standard that is robust. However, their complexity
has caused continued friction in the user experience. Situations such as an
expired certificate, changing the CA on the server, or restricted
filesystem access to a certificate are difficult to diagnose in large part
because SSL libraries do a poor job of error reporting. Connection
negotiation fails, and it can be unclear why.

>From a development perspective, working with client ssl certificates can be
challenging, such as the requirement from many libraries to provide a path
to a certificate on disk.

As such, while client SSL certificates would be a viable solution for pulp
3, a token-based authentication approach would be simpler and more in-line
with how other APIs handle authentication.

Token authentication may be marginally less secure than client SSL
certificates, since the entire token must be sent with every request.
However, in order for that to be compromised (assuming https is in use), a
third party would need the ability to eavesdrop and decrypt the ssl traffic.

Basic Auth


Django and DRF (django rest framework) provide basic auth support out of
the box, including password management. This can be enabled for the entire
REST API and any other views we want.

Tokens
--

Most modern network-based APIs use some variety of token authentication. A
token is a string obtained after proving identity (through basic auth or
some other means), which is used to prove identity for future requests by
including it in an Authorization header.

Authenticating against an external authority can be an expensive operation,
particularly in terms of latency and load on the external service. Using
tokens allows the external authn to take place only once per user within
some period of time.

Tokens normally do not require server-side state. (There are exceptions,
such as DRF's own token support, which stores a random string in the DB
just because it's convenient.) This reduces database dependence and use,
which has slight performance benefits and would allow services to respond
to requests even when the database is unavailable. It also allows trust to
easily be delegated among services.

One advantage that client SSL certs have over tokens is that they can be
explicitly revoked (although doing so may not be easy). Tokens can be
indirectly revoked if they contain an "issued" timestamp. For example, it's
normal for a token-based authn system to reject a token that was issued
before the user's most recent password reset. That said, if tokens are only
being used for authn, user access can and should still be enforced by
authz, so that is another mechanism for turning off a user's access.

DRF includes built-in token support, but it stores tokens in the database.
This adds the characteristics of a session identifier, which is not
desirable for a stateless REST API.

JWT
--

JSON Web Tokens are a popular open standard (RFC 7519) commonly used for
API authentication. They are widely supported by many libraries in many
languages, simple to use, small, and can include arbitrary data as is
useful to the issuing application. Validity is verified by signature and an
optional expiration time.

https://jwt.io/
https://en.wikipedia.org/wiki/JSON_Web_Token

djangorestframework-jwt is a recommended library