0003: Inited the auth GEP

proposals/0003-auth.md

@@ -0,0 +1,112 @@
+---
+GEP: 3
+Title: Authentication & Authorization
+Discussion: TBU
+Implementation: TBU
+---
+# Authentication & Authorization
+
+## Abstract
+
+Glide doesn't support any authentications or authorizations right now. All routers are available to all clients.
+This allows to use Glide only in a limited number of internal use cases.
+
+## Motivation
+
+We need to bring authentication and authorization in some form to
+open up a door for Glide to be used in a wider range of use cases.
+
+Having a notion of user or a session will help with future features like:
+- budgeting
+- usage tracking
+- rate limiting
+- etc.
+
+### Use Cases
+
+- I would like to have authN & authz working out of the box without a need to have a separate user management system in place.
+- I want to limit a number of requests made to a specific router by user/team/org
+- I want to give my user/team/org budgets and ensure they are not going above them
+- I would like to use my existing user management system/SSO to manage my Glide users
+- I would like to tag users to categorize them.
+- I would like to storage some additional metadata in Glide user data
+- I would like to restrict access to a specific set of routers on user/team/org levels
+- I would like to get Glide work with my existing auth servers based on OAuth 2.0 or OIDC
+
+### Requirements
+
+[TBU, list all key requirements to keep in mind, use https://datatracker.ietf.org/doc/html/rfc2119 verbs]
+
+## Design
+
+[TBU, all information about the proposed solution, possibly evaluations against the requirements]
+
+## Other Solution Analysis
+
+### Bricks
+
+The Bricks gateway has a built-in user management admin API.
+The [user model](https://github.com/bricks-cloud/BricksLLM/blob/main/internal/user/user.go) allows to:
+- revoke the users
+- give them access to other resources like models/custom paths/custom API keys (e.g. kinda routers)
+- set budget caps
+- set rate limit limits
+- user's TTL
+- tags (e.g. a list of strings)
+- User ID (e.g. to link it with some external user representation)
+
+Another concept they have is custom API keys that can be linked to a user.
+A custom API key contains this info:
+- revoke status
+- budget and rate limits
+- tags
+- allowed paths
+- should log req/resp
+- rotation enabled?
+- some settings IDs (e.g. provider chat request params)
+- policy ID (e.g. policies have to do with safety rules/PII masking/etc)
+
+Authentication works this way:
+- The service checks a custom key in `X-API-KEY` or `API-KEY` headers
+- try to load it and check the key's restrictions
+- User ID is passed as a part of the request payload (at least for the chat API)
+
+### Tyk OS
+
+TBU
+
+### Traefik
+
+The Traefik Gateway doesn't have a notion of users or sessions. 
+Authentication is implemented as a middleware. The following authN options are supported:
+- Basic Auth
+- Digest Auth
+- Forward Auth (e.g. send a request to another service and if the req failed, it denies processing the original request)
+
+### OpenTelemetry Collector
+
+The OTel Collector is inherently an internal service, but it supports a number of authentications:
+- Basic Auth
+- OAuth2 Client
+- OIDC
+- JIRA Auth
+
+It collects auth-specific info (e.g. claims) and incoming headers to create client identity or context.
+
+### Kong
+
+TBU
+
+### Portkey
+
+TBU
+
+## Future Work
+
+[TBU, what we put outside of the equation now, but may want to consider in the future]
+
+## References
+
+- https://github.com/bricks-cloud/BricksLLM/blob/main/internal/user/user.go
+- https://github.com/apache/apisix/blob/master/docs/en/latest/plugins/authz-keycloak.md
+- https://github.com/spinnaker/gate/tree/master