pirogoeth/lsso

Nginx SSO middleware for protecting your internets.

lsso's Issues

0.4: ensure API requests are allowed.

This is something to keep in the mind for the future and partially take care of now.

The access token API call should be able to be toggled via a configuration switch for security measures.
The same goes for any future API calls that may expose access keys for protected resources.

0.4: testing

There needs to be some way of testing various parts of the codebase.

Both functional and "production" tests need to be run. Maybe this warrants a small Docker-based build with nginx, Redis, etc with a Python test suite to make requests and hit pages?

Without HTTP Basic auth, things get a tad bit more difficult, but still manageable.

0.4: "cumulative" scoping for new requests and upgrades

When creating a new session for a scoped location, ensure that we not only request a token for the location's specified scope, but also for the config.oauth_auth_scope to keep the number of session upgrades that need to happen at a minimum.

Example:

current_scope = none
location -> /auth/test/scope-testing [scope: unix-wheel]
<session creation>
new_current_scope = sso unix-wheel

During a session upgrade, we should make sure to compound current scopes to reduce the number of session upgrades.

Example:

current_scope = sso unix-wheel
location -> /auth/test/scope-testing [scope: container-manage]
<session is killed and recreated>
new_current_scope = sso unix-wheel container-manage

0.4: add scoping to access tokens

Scoping needs to be added to the access token code so temporary tokens can be limited to a subsection of protected pages.

Now, tokens are created with the default config.oauth_auth_scope scope. Scoped access tokens should only be created if the requested scope is in a whitelist/not in a blacklist.

Error messages slightly misleading...

On a bad username or password, the SSO should return msg_bad_credentials through the ?error call back to the auth portal, but returns msg_upstream_error.

0.4: U2F support

Exactly as it sounds -- I want to support U2F registration and auth in the typically lsso workflow.

0.4: allow passing login username through request headers for proxy auth.

Around access.lua#L429, we should be able to add an ngx.req.set_header call to set a header (X-LSSO-Session -- but configurable?) so that the upstream service can use that as an auth method.

This is particularly useful for web applications supporting proxy auth, such as Grafana. This is a good step toward making lsso more powerful.

0.5: move to client credentials grant style OAuth flow.

From the way RFC 6749 reads, client credentials style grant is similar to resource owner password credentials grant, but provides more flexibility.

With the client credentials grant, the main differences are the lack of username and password in the authentication request, as they are provided as HTTP BASIC auth in the Authorization header.

POST /token HTTP/1.1
Host: auth.example.org
Authorization: Basic <base64-mime encoded payload>
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials&scope=space separated scopes

In the case of pyled, authentication and authorization are taken care of in one step, so this request hits a single endpoint and is essentially finished. As for other OAuth systems, I am not sure.