RFE: Add ability to restrict auth by forwarded IP

[Colleen Murphy]

At the Berlin summit, I heard from two different operators that it would be useful to be able to allow users to opt into restricting authentication access by IP address range. This could be implemented as an auth method or more likely as a new user option.

This RFE is a placeholder so we don't forget about it. This should have a spec before it is implemented.

[Morgan Fainberg (mdrnstm)]

This should be implemented after 1807751 (Resource Options For All). This is a good RFE.

[Adrian Turjak (adriant-y)]

So my original thoughts on this when bringing it up is for situations where you want to secure a service/api user with a second factor. Using totp is awkward with an automated account, and means that you'd be storing the password and secret together.

A password + source_ip limited auth could mean that your user can only talk from the given host where your automated services are running. This is also easier than trying to do token handling and totp secrets as part of automated tools and scripts.

This still doesn't really stop a malicious actor from being able to auth after gaining access to the host, but unlike the totp case, they can't take the credentials and then use them from where ever which means they have to continue using the host, and potentially have a higher chance of being spotted.

As for how to implement it, I'd push for it being an auth method because we can then do auth rules as follows:
[['password', 'source_ip'], ['password', 'totp']]

This would be easy right now right as an auth method that just needs to be explicitly defined in your auth request but actually contains just the user id.

 { "auth": {
            "identity": {
                "methods": [
                    "source_ip",
                    "totp"
                ],
                "source_ip": {
                    "user": {
                        "id": "2ed179c6af12496cafa1d279cb51a78f",
                    }
                },
                "password": {
                    "user": {
                        "id": "2ed179c6af12496cafa1d279cb51a78f",
                        "password": "super sekret pa55word"
                    }
                }
            }
        }
    }

Although adding the ability for auth methods to auto-promote themselves could also be interesting. E.g. if a user has the 'source_ip' auth method defined in rules, it auto promotes itself and is checked as part of his auth. Or some other sane auto-promotion mechanism.

Then rather than storing the CIDR for source ip checking in user options, we can keep it in credentials like totp, so the the MFA pattern of keeping 'secrets' in credential stays more consistent (not that CIDR is technically a secret).

[Tobias Urdin (tobias-urdin)]

I agree with Adrian, I won't advocate for any implementation but just for the feature itself.

There is a huge requirement for being able to restrict administrative- and service accounts which is our primary use-case, since authentication right now is very a very vulnerable part in a security aspect of an OpenStack based cloud right now.

It can also be seen as a feature where customers of your cloud could IP restirct there project/user which is a great win if they just want to have access to the account from their office for example.

I would hope that it's implemented in a way that makes project admins/user to be able to restrict their own accounts, but even if that not the case we could make our business logic provision that for them, and I guess users of for example Adjutant could do the same.

[Adrian Turjak (adriant-y)]

@tobias
Most of the APIs to configure MFA in Keystone are admin only, and while I think making them more user friendly may be a good idea it can be a little hard with Keystone.

Essentially, to setup TOTP you shouldn't be able to do so until you can prove you can generate a passcode. Doing that logic in Keystone isn't easy, but we already have a workflow that mostly does that in an Adjutant plugin, which will be rewritten for the current MFA auth-rules based method and moved into master. We can in the process also expand that as a generic set of APIs and Horizon panels for setting up and managing MFA.

Not sure we can really do a check of your source ip before we allow setting it... especially since Horizon pollutes the source ip, but an API call you make could work.

[Adrian Turjak (adriant-y)]

One point I'd also like to add here, and it is an important one, how we implement this has to be VERY configurable around how the headers are parsed. Header spoofing, which ones to trust, which parts of the header (or which of the multiple headers) to trust, etc. All those are potential vectors we need to try and handle, or at least supply methods which will allow deployers to make sure the correct headers are used and parsed.

"X-Forwarded-For", and "Forwarded" potentially, plus I have a feeling there are some odd custom ones out there too.

We'll need to investigate this, and make sure we are handling this as best as we can.

[Tobias Urdin (tobias-urdin)]

Was there any progress on this topic or to 1807751 (Resource Options For All) that could be used for this purpose?