生CAx软件是在设计时便将云平台作为部署、运行环境的CAx软件。通常，为了降低成本、方便管理，云原生CAx系统需要能为多个租户提供服务，即多租户(Multi-tenancy)，而实现这种多租户系统，关键是要处理好身份认证、权限控制、资源隔离等问题。
Sharing clusters saves costs and simplifies administration. However, sharing clusters also presents challenges such as security, fairness, and managing noisy neighbors.
云原生平台一般提供了资源隔离的方案。比如，在K8s中，可以通过命名空间(namespace)等方式轻松实现资源的隔离。因此，本文仅总结身份认证、权限管等方面的技术。
注1：限于研究水平，分析难免不当，欢迎批评指正。
注2：文章内容会不定期更新。
一、HTTP Access Authentication
Ref. from Hypertext Transfer Protocol -- HTTP/1.0: Access Authentication
HTTP provides a simple challenge-response authentication mechanism which may be used by a server to challenge a client request and by a client to provide authentication information.
The 401 (unauthorized) response message is used by an origin server to challenge the authorization of a user agent. The WWW-Authenticate response-header field must be included in 401 (unauthorized) response messages. The field value consists of at least one challenge that indicates the authentication scheme(s) and parameters applicable to the Request-URI.
WWW-Authenticate = "WWW-Authenticate" ":" 1#challenge auth-scheme = token auth-param = token "=" quoted-string challenge = auth-scheme 1*SP realm *( "," auth-param ) realm = "realm" "=" realm-value realm-value = quoted-stringA user agent that wishes to authenticate itself with a server-- usually, but not necessarily, after receiving a 401 response--may do so by including an Authorization header field with the request. The Authorization field value consists of credentials containing the authentication information of the user agent for the realm of the resource being requested.
Authorization = "Authorization" ":" credentials credentials = basic-credentials | ( auth-scheme #auth-param )If the server does not wish to accept the credentials sent with arequest, it should return a 403 (forbidden) response.
The HTTP protocol does not restrict applications to this simple challenge-response mechanism for access authentication. Additional mechanisms may be used, such as encryption at the transport level or via message encapsulation, and with additional header fields specifying authentication information.
The "basic" authentication scheme is based on the model that the useragent must authenticate itself with a user-ID and a password for each realm.
basic-credentials = "Basic" SP basic-cookie basic-cookie = <base64 [5] encoding of userid-password, except not limited to 76 char/line> userid-password = [ token ] ":" *TEXTUpon receipt of an unauthorized request for a URI within the protection space, the server should respond with a challenge like the following:
WWW-Authenticate: Basic realm="WallyWorld"where "WallyWorld" is the string assigned by the server to identify the protection space of the Request-URI.
If the user agent wishes to send the user-ID "Aladdin" and password "open sesame", it would use the following header field:
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==The basic authentication scheme is a non-secure method of filtering unauthorized access to resources on an HTTP server. It is based on the assumption that the connection between the client and the server can be regarded as a trusted carrier. As this is not generally true on an open network, the basic authentication scheme should be used accordingly.
二、 Cookies
Ref. from HTTP State Management Mechanism draft-abarth-cookie-07
The origin server initiates a session, if it so desires, by including a Set-Cookie header in an HTTP response. Using the Set-Cookie header, an HTTP server can store name/value pairs (called cookies) at the user agent.
When the user agent generates an HTTP request, the user agent SHOULD attach exactly one HTTP header named Cookie if the cookie-string (defined below) for the Request-URI is non-empty. A user agent MAY elide the Cookie header in its entirety if the user agent is configured to block sending cookies.
三、JWT
Ref. from JWT
JSON Web Token (JWT) is a compact claims representation format intended for space constrained environments such as HTTP Authorization headers and URI query parameters. JWTs encode claims to be transmitted as a JSON [RFC7159] object that is used as the payload of a JSON Web Signature (JWS) [JWS] structure or as the plaintext of a JSON Web Encryption (JWE) [JWE] structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted. JWTs are always represented using the JWS Compact Serialization or the JWE Compact Serialization.
A JWT is represented as a sequence of URL-safe parts separated by period ('.') characters. Each part contains a base64url-encoded value. The number of parts in the JWT is dependent upon the representation of the resulting JWS using the JWS Compact Serialization or JWE using the JWE Compact Serialization.
网络资料
Kubernetes: Multi-tenancy
https://kubernetes.io/docs/concepts/security/multi-tenancy/
Hypertext Transfer Protocol -- HTTP/1.0https://datatracker.ietf.org/doc/html/rfc1945#autoid-1
HTTP Access Authenticationhttps://datatracker.ietf.org/doc/html/rfc1945#section-11
JSON Web Token (JWT)https://datatracker.ietf.org/doc/html/rfc7519
JSON Web Signature (JWS)https://www.rfc-editor.org/rfc/rfc7515.htmlJSON Web Encryption (JWE)https://www.rfc-editor.org/rfc/rfc7516.html