authentication - ¿Cómo manejar la autenticación y autorización con thrift?
authorization rpc (3)
Las tareas como la autorización y los permisos no se consideran parte de Thrift, principalmente porque estas cosas (generalmente) están más relacionadas con la lógica de la aplicación que con un concepto general de RPC / serialización. La única cosa que Thrift admite ahora es el TSASLTransport
. No puedo decir mucho sobre eso, simplemente porque nunca sentí la necesidad de usarlo.
La otra opción podría ser utilizar THeaderTransport
que desafortunadamente en el momento de la redacción solo se implementa con C ++. Por lo tanto, si planea usarlo con otro idioma, es posible que tenga que invertir algún trabajo adicional. No hace falta decir que aceptamos contribuciones ...
Estoy desarrollando un sistema que utiliza el ahorro. Me gustaría que se verifique la identidad de los clientes y que se realicen las operaciones de ACL. ¿Thrift proporciona algún apoyo para esos?
No directamente. La única forma de hacer esto es tener un método de autenticación que cree una clave (temporal) en el servidor, y luego cambie todos sus métodos para que el primer argumento sea esta clave y, además, todos generen un error no autenticado. Por ejemplo:
exception NotAuthorisedException {
1: string errorMessage,
}
exception AuthTimeoutException {
1: string errorMessage,
}
service MyAuthService {
string authenticate( 1:string user, 2:string pass )
throws ( 1:NotAuthorisedException e ),
string mymethod( 1:string authstring, 2:string otherargs, ... )
throws ( 1:AuthTimeoutException e, ... ),
}
Usamos este método y guardamos nuestras claves en una instancia de memcached segura con un tiempo de espera de 30 minutos para que las claves mantengan todo "rápido". Se espera que los clientes que reciben una AuthTimeoutException
vuelvan a autorizar y vuelvan a intentarlo, y tenemos algunas reglas de firewall para detener los ataques de fuerza bruta.
Un poco tarde (creo que muy tarde) pero había modificado el código de Thrift Source para esto hace un par de años.
Acaba de enviar un ticket con el parche a https://issues.apache.org/jira/browse/THRIFT-4221 solo por esto.
Echa un vistazo a eso. Básicamente, la propuesta es agregar un enlace "BeforeAction" que haga exactamente eso.
Ejemplo de diferencia generada por Golang
+ // Called before any other action is called
+ BeforeAction(serviceName string, actionName string, args map[string]interface{}) (err error)
+ // Called if an action returned an error
+ ProcessError(err error) error
}
type MyServiceClient struct {
@@ -391,7 +395,12 @@ func (p *myServiceProcessorMyMethod) Process(seqId int32, iprot, oprot thrift.TP
result := MyServiceMyMethodResult{}
var retval string
var err2 error
- if retval, err2 = p.handler.MyMethod(args.AuthString, args.OtherArgs_); err2 != nil {
+ err2 = p.handler.BeforeAction("MyService", "MyMethod", map[string]interface{}{"AuthString": args.AuthString, "OtherArgs_": args.OtherArgs_})
+ if err2 == nil {
+ retval, err2 = p.handler.MyMethod(args.AuthString, args.OtherArgs_)
+ }
+ if err2 != nil {
+ err2 = p.handler.ProcessError(err2)