Support for OpenID based authentication

[itsmurugappan]

Support for OpenID based authentication

why open id ?

1. enterprise standard to support variety of user flows.
2. connect various to various identity broker like github, ldap
3. All major languages have open id packages

Openfaas currently supports basic authentication. If it has to support openid based auth either

1. gateway has to be changed
2. proxy in front of gateway

To get started we can just have proxy like keycloak gatekeeper in front of openfaas gateway and proxy all requests through it. (No change needed on the gateway)

So what are the changes needed ?

3 ways to connect to openfaas gateway

1. ui
2. api
3. cli

ui - we can use redirect flow, which will redirect to openid providers ui and can login from there api - bearer token in header cli - cli is the one which needs change. Need a way to pass bearer token

my proposal

add functionality to the login, similar to openshift login (oc login)

For example

faas login -u -p --gateway=https://openfaasgateway --well-know-url=openidurl client=openidclient

• once logged in the open id token can be stores in the config file.
• every request to gateway made with the token in the header
• once the token expires , alert for login again

[alexellis]

Hi, thanks for your interest in the project.

Here are some thoughts/questions:

Adding OAuth2 is not a trivial feature and will be expensive for the community to develop and maintain.

What OAuth flows are you hoping to support and implement?

Once you have authentication, how are you going to implement authorization re: claims and permissions?

To get started we can just have proxy like keycloak gatekeeper in front of openfaas gateway and proxy all requests through it. (No change needed on the gateway)

You mentioned gatekeeper. Have you taken a look at OAuth2Proxy? Does it do what you need?

You may also want to look at OpenFaaS Cloud which includes OAuth2 and integration with GitLab self-hosted and GitHub.com.

[itsmurugappan]

Hi Alex,

Thanks for the reply. OAuth2Proxy does what I need. If the OAuth2Proxy protects the openfaas create, delete, list api's, I will need a way to pass the access token in the header to get authorized. That's the reason I am proposing a change in CLI, which I can contribute to.

[alexellis]

When you have time please can you answer my other questions?

[itsmurugappan]

What OAuth flows are you hoping to support and implement?

I had Password grant in mind.

Once you have authentication, how are you going to implement authorization re: claims and permissions?

This can be handled in the gatekeeper or oauth2_proxy. I was planning to authorize based on issuer, audience and role claims (member of an email group)

[alexellis]

How are you planning to relate those roles/claims to the various parts of the OpenFaaS API?

[alexellis]

For me to entertain this suggestion further, I'd like to see a lot more from your side about how you expect it to work for both authentication and more importantly authorisation. The current API model does not map to claims or roles other than one user being the a service-account with full permissions to all APIs.

Here are some more details on what is expected from a proposal: https://github.com/openfaas/faas/blob/master/CONTRIBUTING.md#i-have-a-great-idea

I'm looking forward to hearing more.

[itsmurugappan]

Sure. I will give details of the proposal soon.

[itsmurugappan]

About the Solution

Proxy requests to Openfaas gateway through a reverse proxy (key cloak gatekeeper or oauth proxy) which integrates with an open id provider

Authentication: The user will authenticate with open id provider to get the access token. Below I have described how each flow will work.

UI: Redirect flow of the reverse proxy API: Request the access token through api call to open id provider Example: curl -X POST https://keycloak/auth/realms/realmname/protocol/openid-connect/token -H "Content-Type: application/x-www-form-urlencoded" -d 'username=uname&password=pass&grant_type=password&client_id=openfaas'

There are also packages available in each programming language to achieve the same

CLI: Similar to API flow, login functionality has to be added to cli to accept user credentials, hit the open id provider and store the access token in the config file.

Authorization:

• Reverse proxy will verify the user access through the access token provided by the user.
• The reverse proxy will verify for issuer, audience and roles to check whether the user is part of email group to see if he/she can be given access to the api’s.
• Once the user is authorized the user will have access to all openfaas gateway api’s.
• This reverse proxy is a configurable service, claim matching can be configured according to the user needs.

Changes required in the Openfaas-cli

Login Command:

• Take user credentials, openid url and open id client name as input.
• Call the password grant api of open id provider and get the access token
• Store the access token in openfaas cli config file

Mock cli change: faas-cli login -u user -p password --gateway http://127.0.0.1:8080 --auth-url=https://oidcprovider/auth/realms/realmname/protocol/openid-connect/token --client=oidcclientname

Deploy/Delete/Describe/List/Invoke Command:

• Since all these commands call the gateway. The access token has to be passed in the header.
• Fetch the token from the config file and pass the access token in the header.
• If the token has expired, prompt to login again.
• No changes to cli parameters

Pros:

• Enterprise grade security for Openfaas gateway.
• Variety of open id providers can be plugged in.
• Fine grained security

Effort Required:

Changed are required only in Faas-CLI. In FaaS-CLI following changes are needed

1. Login command
2. Deploy/Delete/Describe/List/Invoke commands

Migration Strategy/Backwards Compatibility:

The reverse proxy is optional component. If the user opts to use basic auth this component is not needed. From the cli perspective, additional parameters will be added to the login flow only. Since these parameters are optional it will not affect the compatibility with Open FaaS gateway without a proxy in front.

[alexellis]

Once the user is authorized the user will have access to all openfaas gateway api’s.

I'm not sure what the benefits are of using a password-grant which means any user with a single role is a complete admin? How is that enterprise-grade security? It seems pretty much the same as basic-auth.

What I would envision for enterprise-grade OAuth2 is more like:

• All OpenFaaS Gateway APIs are scoped to claims or roles
• No use of password-grant
• Full authorization of all users
• OpenID connect to provide authentication and authorization claims / roles

[itsmurugappan]

Thanks for the comments. I made the following changes.

1. Authorization at API level

The proxy with open id integration like gatekeeper gives the flexibility of authorizing at api level. For example, if we want to restrict the function deployment to developers_write role. Following would be configuration for the gatekeeper.

resources:
- uri: /system/function
  methods:
  - GET
  roles:
  - developers_read
- uri: /system/function
  methods:
  - POST
  roles:
  - developers_write

Can enforce authorization for all api's listed here .

2. Use the authorization code grant flow for the cli access instead of password grant.

[CrystalMethod]

I would be more than happy to test such feature.

[alexellis]

Hi @CrystalMethod @itsmurugappan I would like your input on the new OIDC flow implemented for OpenFaaS.

It's being tracked by the openfaas/faas issue and the CLI issue I raised.

https://github.com/openfaas/faas-cli/issues/647 https://github.com/openfaas/faas/issues/1175

cc @prahaladdarkin

Alex

[itsmurugappan]

sure @alexellis . Will check out this weekend. Got some great updates from you regarding tls and oidc.