Today we continue with the threat assessment of keycloak deployment on Kubernetes cluster.
Storing of the data exchanged from the system to the user is generally outside the trust boundary. If the data is tampered, hijacked or compromised, the activities within the trust boundary can be manipulated. This makes the system vulnerable and therefore validation of the data becomes important activity within each component.
The data usually comprises of a token along with attributes that are made available by the issuing Keycloak service broker in Json format. Since this is part of the OAuth protocol, the mechanisms of the protocol already mitigate security vulnerabilities pertaining to the data. It is just the handling of the data after the protocol has issued them that needs to be secured. Again, this falls outside the trust boundary and as such is largely on the user side of responsibilities. The system takes efforts only to validate the data. After validation, it is assumed that the token belongs to the identity to whom the token was issued. If the token is not hijacked, only registered and authorized users can take action on the system.
Tokens are not restricted to users. Client credential access grants tokens to clients from the issuing authority. Clients and users are both registered so their requests are only honored if they can be looked up.
In the case of deployment of Keycloak service broker over Kubernetes clusters, we validate the integration between Keycloak service broker, the service catalog and the open service broker API. We assume each component is independently assessed with their STRIDE model and only secure the integration. Since the Keycloak service broker fits nicely into the open service broker API framework of Kubernetes, we can take it to be internal.
Therefore, we evaluate only the Keycloak deployment. This deployment consists of an identity provider together with the broker. In future, there may be more than one identity provider. A user goes to the identity provider to login. This is just how OAuth operates where all requests for user tokens are initiated by redirecting the user to the login screen of the identity provider. Since a user interface is involved the interaction between the user and the IDP is now subject to all the threats that a web interface faces. Threats such as cross site scripting, man-in-the-middle attacks, SQL injection attacks, cross-origin resource sharing and others are all vulnerabilities exploited from the client side. Enabling browser traffic to be over https mitigates only some of these concerns as transport is only a layer below the application logic.
Storing of the data exchanged from the system to the user is generally outside the trust boundary. If the data is tampered, hijacked or compromised, the activities within the trust boundary can be manipulated. This makes the system vulnerable and therefore validation of the data becomes important activity within each component.
The data usually comprises of a token along with attributes that are made available by the issuing Keycloak service broker in Json format. Since this is part of the OAuth protocol, the mechanisms of the protocol already mitigate security vulnerabilities pertaining to the data. It is just the handling of the data after the protocol has issued them that needs to be secured. Again, this falls outside the trust boundary and as such is largely on the user side of responsibilities. The system takes efforts only to validate the data. After validation, it is assumed that the token belongs to the identity to whom the token was issued. If the token is not hijacked, only registered and authorized users can take action on the system.
Tokens are not restricted to users. Client credential access grants tokens to clients from the issuing authority. Clients and users are both registered so their requests are only honored if they can be looked up.
In the case of deployment of Keycloak service broker over Kubernetes clusters, we validate the integration between Keycloak service broker, the service catalog and the open service broker API. We assume each component is independently assessed with their STRIDE model and only secure the integration. Since the Keycloak service broker fits nicely into the open service broker API framework of Kubernetes, we can take it to be internal.
Therefore, we evaluate only the Keycloak deployment. This deployment consists of an identity provider together with the broker. In future, there may be more than one identity provider. A user goes to the identity provider to login. This is just how OAuth operates where all requests for user tokens are initiated by redirecting the user to the login screen of the identity provider. Since a user interface is involved the interaction between the user and the IDP is now subject to all the threats that a web interface faces. Threats such as cross site scripting, man-in-the-middle attacks, SQL injection attacks, cross-origin resource sharing and others are all vulnerabilities exploited from the client side. Enabling browser traffic to be over https mitigates only some of these concerns as transport is only a layer below the application logic.
No comments:
Post a Comment