Sheng CAx software is a CAx software that takes the cloud platform as the deployment and operating environment when it is designed . Usually, in order to reduce costs and facilitate management, the cloud-native CAx system needs to be able to provide services for multiple tenants, that is, multi-tenancy ( Multi-tenancy ), and the key to realizing this multi-tenancy system is to properly handle issues such as identity authentication , authority control , and resource isolation .
Sharing clusters saves costs and simplifies administration. However, sharing clusters also presents challenges such as security, fairness, and managing noisy neighbors.
Cloud-native platforms generally provide resource isolation solutions. For example, in K8s , resources can be easily isolated through namespaces and other means. Therefore, this article only summarizes the technologies of identity authentication and authority management .
Note 1: Limited to the research level, the analysis is inevitably inappropriate, criticism and correction are welcome.
Note 2: The content of the article will be updated from time to time.
一、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.
2. 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.
3. 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.
network information
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